No Boot in Clover

[haus_k]

this section looks incorrect:

<key>DeviceProperties</key>
    <dict>
        <key>Add</key>
        <dict>
            <key>PciRoot(0x0)/Pci(0x16,0x0)</key>
            <dict>
                <key>device-id</key>
                <data>OhwAAA==</data>
            </dict>
            <key>AAPL,snb-platform-id</key>
            <data>EAADAA==</data>
            <key>device-id</key>
            <data>JgEAAA==</data>
        </dict>

take a pic where is stops and post the pic here

The properties referred to by you as incorrect are for iGPU, which I will never use to drive a display. In this case, do I have to set the properties to only use the iGPU for computing tasks, like described at https://dortania.github.io/OpenCore-Install-Guide/config.plist/sandy-bridge.html#deviceproperties ?

 

[Feartech]

The properties referred to by you as incorrect are for iGPU, which I will never use to drive a display. In this case, do I have to set the properties to only use the iGPU for computing tasks, like described at https://dortania.github.io/OpenCore-Install-Guide/config.plist/sandy-bridge.html#deviceproperties ?

yes, you have it incorrect

 

[haus_k]

this section looks incorrect:

<key>DeviceProperties</key>
    <dict>
        <key>Add</key>
        <dict>
            <key>PciRoot(0x0)/Pci(0x16,0x0)</key>
            <dict>
                <key>device-id</key>
                <data>OhwAAA==</data>
            </dict>
            <key>AAPL,snb-platform-id</key>
            <data>EAADAA==</data>
            <key>device-id</key>
            <data>JgEAAA==</data>
        </dict>

take a pic where is stops and post the pic here

My third serious attempt today to update my signature build to Monterey. I made a brand new Monterey Install USB, compiled a brand new EFI OC, made a brand new handmade config.plist and ended up with a complete failure. I am still using the SSDTs downloaded from the forums here. The pic you asked me to take, of where it stops, is "stop.jpg". I am also attaching my new Install USB's EFI + my working Mojave Clover 4934's EFI ("EFI_c4934") + screenshots of my BIOS settings ("bios1.jpg" to "bios4.jpg"). I know my BIOS very well so please rely on these 4 screenshots, they show everything significant except the serial com port which is disabled. I am feeling a bit sad today. Thank you for your help.

 

[Feartech]

My third serious attempt today to update my signature build to Monterey. I made a brand new Monterey Install USB, compiled a brand new EFI OC, made a brand new handmade config.plist and ended up with a complete failure. I am still using the SSDTs downloaded from the forums here. The pic you asked me to take, of where it stops, is "stop.jpg". I am also attaching my new Install USB's EFI + my working Mojave Clover 4934's EFI ("EFI_c4934") + screenshots of my BIOS settings ("bios1.jpg" to "bios4.jpg"). I know my BIOS very well so please rely on these 4 screenshots, they show everything significant except the serial com port which is disabled. I am feeling a bit sad today. Thank you for your help.

your stop image is a little pointless though...

maybe disabled logo so we can see what the issue it?

 

[haus_k]

I disabled "full screen logo" in BIOS now the "stop2.png" is even pointlesser. Going into boot options with F12 ("bootop.jpg") and choosing the USB ends me up on a black screen. I use my signature build since 2011 and am quite familiar with its behavior. It seems to me that the motherboard and processor come up when I switch the setup on, but that is all that happens. Nothing starts to load or process. The whole setup just idles after being switched on, no matter what BIOS setting I change. There does not seem to be any bootup software on the USB that causes any kind of computer activity. If I hit the main power button it just switches off again without the slightest delay.

 

[haus_k]

your stop image is a little pointless though...

maybe disabled logo so we can see what the issue it?

In full awareness of how important patience is here, please allow me to humbly ask if I can still count on your support, or is my case to be considered lost? Much obliged!

 

[Feartech]

In full awareness of how important patience is here, please allow me to humbly ask if I can still count on your support, or is my case to be considered lost? Much obliged!

your images are not much to go on though is there?

it is difficult to help with out more info

re check all your bios settings and your EFI

also use a decent USB installer stick, Sandisk are pretty good ones to use, up to 32GB

 

[haus_k]

I am now using a USB SanDisk 3.2Gen1 Media with 32GB. I made the bootable Monterey USB using the local guide once more. But I am working on Mojave so the app Disc Utility does not give me the option to "Click Current and choose 1 Partition" instead there is already 1 partition when I format the drive as GUID / MacOS Ext. Journ. This can't be the problem, can it? OK so silly me thought I'd give Clover5157 another try for my next Monterey attempt, as I am using Clover4934 on my Mojave build and it works excellently. I thought maybe I can refer to the config.plist of my Mojave Clover build and see where it gets me with the config.plist on my Monterey USB's Clover EFI. But, formatting the EFI as FAT32 does not work as I get a permission denial (see screenshot). Any point in continuing? I expect you will again advise me to go for OpenCore... but I just loved the easyness of Clover and it worked great for me since 2011 El Capitan so... By the way, ever since I started working on the Monterey update my Mojave also changed its bootup process, it is now seemingly in verbose mode as it lists all the code steps. (Could this be caused by the -v boot flag set in the OpenCore config.plist of the Monterey USB? I so do not get it...) And ever so often, my Mojave build now panics on bootup, always at the same spot. Could this be a general problem ? I also attached the screenshot of the panic. Thanks.

 

[Feartech]

I am now using a USB SanDisk 3.2Gen1 Media with 32GB. I made the bootable Monterey USB using the local guide once more. But I am working on Mojave so the app Disc Utility does not give me the option to "Click Current and choose 1 Partition" instead there is already 1 partition when I format the drive as GUID / MacOS Ext. Journ. This can't be the problem, can it? OK so silly me thought I'd give Clover5157 another try for my next Monterey attempt, as I am using Clover4934 on my Mojave build and it works excellently. I thought maybe I can refer to the config.plist of my Mojave Clover build and see where it gets me with the config.plist on my Monterey USB's Clover EFI. But, formatting the EFI as FAT32 does not work as I get a permission denial (see screenshot). Any point in continuing? I expect you will again advise me to go for OpenCore... but I just loved the easyness of Clover and it worked great for me since 2011 El Capitan so... By the way, ever since I started working on the Monterey update my Mojave also changed its bootup process, it is now seemingly in verbose mode as it lists all the code steps. (Could this be caused by the -v boot flag set in the OpenCore config.plist of the Monterey USB? I so do not get it...) And ever so often, my Mojave build now panics on bootup, always at the same spot. Could this be a general problem ? I also attached the screenshot of the panic. Thanks.

later versions of clover require a lot of opencore elements added to the config.plist to make it work

probably better to use opencore instead

-v enables verbose mode

the panic has gone off the screen in your image

usb2 sticks are better to use

 

[haus_k]

ok just to get this straight in my head: The Monterey USB's OpenCore config.plist injected the "-v" boot arg (and all other there definded boot args) into my Mojave Clover drive’s EFI even though the Mojave Clover drive was detached...? How? Or is the boot arg injected into the BIOS? I would so much like to understand.

About the panic: Can you work with the attached pics? I have taken stills from a video grab of the verbose boot process and tried to make it as readable as possible, but some screens are just to fast to grab...