Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30960 posts in this topic

Recommended Posts

SoThOr
SoThOr
Posted
Posted
57 minutes ago, apianti said:

 

What build version? My point is that bcdboot is what initializes the BCD, according to the documentation bcdboot can only set windows boot manager and bcdedit can only read entries from the BCD. Did you ADD an entry and then it appeared in that list? Because changing the order is simply matching the order of variables. Since literally NONE of my five computers display any of these entries, they had to have been created by bcdboot when creating the BCD. I always install windows first, but even my surface pro and stick pc do not show these entries and windows was preinstalled, is the same version, and both have other OSes as well. Sigh... I literally just described to you a situation where windows can be booted from a different location BY DESIGN.

 

 

Why would windows detect itself as a firmware application? That leads me to believe that it is indeed just copying firmware variables when bcdboot creates the BCD. Does your other windows install still exist? Does it say that the other one is there as a firmware application?

 

Also, I'm literally just done. I cannot stand this community anymore. I'm done. Have a great time guys but I'm just done, I don't care at all anymore. Goodbye.

So it appears my firmware was set to show legacy devices in boot options and adding those additional devices. I disabled that option and now bcdedit shows:

Spoiler

C:\WINDOWS\system32>bcdedit /enum FIRMWARE

Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {823d4ef6-7373-11e9-9caf-806e6f6e6963}
                        {eace909f-3cb3-11e5-b87a-c28123693819}
timeout                 1

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume4
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {631bdfec-580c-11e8-9c1a-9d7903c42521}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 0

Firmware Application (101fffff)
-------------------------------
identifier              {823d4ef6-7373-11e9-9caf-806e6f6e6963}
device                  partition=G:
description             UEFI: Lexar USB Flash Drive 1100

Firmware Application (101fffff)
-------------------------------
identifier              {eace909f-3cb3-11e5-b87a-c28123693819}
device                  partition=\Device\HarddiskVolume8
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager

The second \EFI\Microsoft\Boot\bootmgfw.efi is from an old Windows 8 install. When I upgraded to Windows 10 I installed an SSD into my system and installed it there. The OS is still there and it has an additional EFI partition. I can't recall exactly what I did but I believe I may have disconnected all other drives when I installed Windows 10.

 

And to show that bcdedit is showing the boot variables I booted into EFI shell from a USB stick and used "bcfg boot dump". Before disabling legacy boot:

Spoiler

Option: 00. Variable: Boot0000   
  Desc    - Windows Boot Manager
  DevPath - HD(2,GPT,1aca364d-82dd-4f63-ac0e-aa9aa224e877,0xe1800,0x31800)/\EFI\Microsoft\Boot\bootmgfw.efi
  Optional- Y
Option: 01. Variable: Boot0004   
  Desc    - Windows Boot Manager
  DevPath - HD(2,GPT,8429c978-b940-4995-82c2-1981df946ece,0x96800,0x32000)/\EFI\Microsoft\Boot\bootmgfw.efi
  Optional- N
Option: 02. Variable: Boot0008   
  Desc    - UEFI: Lexar USB Flash Drive 1100
  DevPath - PciRoot(0x0)/Pci(0x1d,0x0)/USB(0x1,0x0)/USB(0x5,0x0)/USB(0x3,0x0)/HD(1,MBR,0x00020fa6,0x3f,0x64000)
  Optional- Y
Option: 03. Variable: Boot0005   
  Desc    - Samsung SSD 850 EVO 500GB
  DevPath - BBS(HD,)
  Optional- Y
Option: 04. Variable: Boot0006   
  Desc    - ST3500320AS
  DevPath - BBS(HD,)
  Optional- Y
Option: 05. Variable: Boot0007   
  Desc    - WDC WD30EFRX-68EUZN0
  DevPath - BBS(HD,)
  Optional- Y
Option: 06. Variable: Boot0009   
  Desc    - Lexar USB Flash Drive 1100
  DevPath - BBS(HD,)
  Optional- Y
Option: 07. Variable: Boot0003   
  Desc    - ASUS    DRW-20B1LT
  DevPath - BBS(CDROM,)
  Optional- Y

 

After disabling legacy boot:

Spoiler

Option: 00. Variable: Boot0000   
  Desc    - Windows Boot Manager
  DevPath - HD(2,GPT,1aca364d-82dd-4f63-ac0e-aa9aa224e877,0xe1800,0x31800)/\EFI\Microsoft\Boot\bootmgfw.efi
  Optional- Y
Option: 01. Variable: Boot0008   
  Desc    - UEFI: Lexar USB Flash Drive 1100
  DevPath - PciRoot(0x0)/Pci(0x14,0x0)/USB(0x9,0x0)/USB(0x3,0x0)/HD(1,MBR,0x00020fa6,0x3f,0x64000)
  Optional- Y
Option: 02. Variable: Boot0004   
  Desc    - Windows Boot Manager
  DevPath - HD(2,GPT,8429c978-b940-4995-82c2-1981df946ece,0x96800,0x32000)/\EFI\Microsoft\Boot\bootmgfw.efi
  Optional- N

 

While the name suggests its for BCD it is also able to read and alter boot variables in nvram, in a rather convoluted, obscure, Microsoft manner. It has to make it into \EFI\Microsoft\Boot\bootmgfw.efi somehow for any BCD entries to be relevant so being able to change the UEFI boot variables with bcdedit does make some sense. 

 

I apologize if came off aggressive towards you apianti. It wasn't my intention. I just wanted to add my experience with bcdedit to the conversation. What I meant was I don't understand why if you have Clover and Linux configured in your firmware that it doesn't show in bcdedit because from my experience I would expect to see there. As you can see on my system that "bcdedit /enum FIRMWARE" shows very similar information as "bcfg boot dump" and a change from the firmware settings changed something in bcdedit.

apianti
apianti
Posted
Posted (edited)

No, I'm just generally irritated by the fact that I research things, say what is going on, people say some nonsense, I provide documentation/evidence, no one reads it, and then says the same things without any evidence to the contrary of what I said. For instance, I am in windows 10, plugged in an ubuntu installer and ran these commands, at no point did I restart:

 

Spoiler

C:\WINDOWS\system32>bcdboot C:\Windows /s F: /f UEFI /p /d
Boot files successfully created.

C:\WINDOWS\system32>bcdedit /enum all

Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {ddc6602b-7388-11e9-be05-806e6f6e6963}
timeout                 1

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {459d8026-7384-11e9-be04-d0509976b8c9}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 0

Firmware Application (101fffff)
-------------------------------
identifier              {ddc6602b-7388-11e9-be05-806e6f6e6963}
device                  partition=F:
description             UEFI: PNY USB 2.0 FD 0.00

Windows Boot Loader
-------------------
identifier              {41f2a636-4ded-11e8-8371-f56bc31a9418}
device                  ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{41f2a637-4ded-11e8-8371-f56bc31a9418}
path                    \windows\system32\winload.efi
description             Windows Recovery Environment
locale                  en-US
inherit                 {bootloadersettings}
displaymessage          Recovery
osdevice                ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{41f2a637-4ded-11e8-8371-f56bc31a9418}
systemroot              \windows
nx                      OptIn
bootmenupolicy          Standard
winpe                   Yes

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \WINDOWS\system32\winload.efi
description             Windows 10
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {85b68803-7385-11e9-8525-80c21444cd72}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \WINDOWS
resumeobject            {459d8026-7384-11e9-be04-d0509976b8c9}
nx                      OptIn
bootmenupolicy          Standard

Windows Setup
-------------
identifier              {7254a080-1510-4e85-ac0f-e7fb3d444736}
device                  ramdisk=[C:]\$WINDOWS.~BT\Sources\SafeOS\winre.wim,{459d8028-7384-11e9-be04-d0509976b8c9}
bootstatdevice          partition=C:
custom:11000083         partition=C:
path                    \windows\system32\winload.efi
description             Windows Rollback
locale                  en-US
bootstatfilepath        \$WINDOWS.~BT\Sources\SafeOS\bootstat.dat
inherit                 {bootloadersettings}
restartonfailure        Yes
osdevice                ramdisk=[C:]\$WINDOWS.~BT\Sources\SafeOS\winre.wim,{459d8028-7384-11e9-be04-d0509976b8c9}
custom:21000152         partition=C:
systemroot              \windows
nx                      OptIn
bootmenupolicy          Standard
winpe                   Yes

Windows Boot Loader
-------------------
identifier              {7d97a531-547d-11e5-a131-f9d2080e85a8}
device                  ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{7d97a532-547d-11e5-a131-f9d2080e85a8}
path                    \windows\system32\winload.efi
description             Windows Recovery Environment
locale                  en-US
inherit                 {bootloadersettings}
displaymessage          Recovery
osdevice                ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{7d97a532-547d-11e5-a131-f9d2080e85a8}
systemroot              \windows
nx                      OptIn
bootmenupolicy          Standard
winpe                   Yes

Windows Boot Loader
-------------------
identifier              {85b68803-7385-11e9-8525-80c21444cd72}
device                  ramdisk=[\Device\HarddiskVolume5]\Recovery\WindowsRE\Winre.wim,{85b68804-7385-11e9-8525-80c21444cd72}
path                    \windows\system32\winload.efi
description             Windows Recovery Environment
locale                  en-US
inherit                 {bootloadersettings}
displaymessage          Recovery
osdevice                ramdisk=[\Device\HarddiskVolume5]\Recovery\WindowsRE\Winre.wim,{85b68804-7385-11e9-8525-80c21444cd72}
systemroot              \windows
nx                      OptIn
bootmenupolicy          Standard
winpe                   Yes

Resume from Hibernate
---------------------
identifier              {41f2a634-4ded-11e8-8371-f56bc31a9418}
device                  partition=C:
path                    \WINDOWS\system32\winresume.efi
description             Windows Resume Application
locale                  en-US
inherit                 {resumeloadersettings}
recoverysequence        {41f2a636-4ded-11e8-8371-f56bc31a9418}
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
filedevice              partition=C:
filepath                \hiberfil.sys
bootmenupolicy          Standard
debugoptionenabled      No

Resume from Hibernate
---------------------
identifier              {459d8026-7384-11e9-be04-d0509976b8c9}
device                  partition=C:
path                    \WINDOWS\system32\winresume.efi
description             Windows Resume Application
locale                  en-US
inherit                 {resumeloadersettings}
recoverysequence        {85b68803-7385-11e9-8525-80c21444cd72}
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
filedevice              partition=C:
filepath                \hiberfil.sys
bootmenupolicy          Standard
debugoptionenabled      No

Windows Memory Tester
---------------------
identifier              {memdiag}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\memtest.efi
description             Windows Memory Diagnostic
locale                  en-US
inherit                 {globalsettings}
badmemoryaccess         Yes

EMS Settings
------------
identifier              {emssettings}
bootems                 No

Debugger Settings
-----------------
identifier              {dbgsettings}
debugtype               Serial
debugport               1
baudrate                115200

RAM Defects
-----------
identifier              {badmemory}

Global Settings
---------------
identifier              {globalsettings}
inherit                 {dbgsettings}
                        {emssettings}
                        {badmemory}

Boot Loader Settings
--------------------
identifier              {bootloadersettings}
inherit                 {globalsettings}
                        {hypervisorsettings}

Hypervisor Settings
-------------------
identifier              {hypervisorsettings}
hypervisordebugtype     Serial
hypervisordebugport     1
hypervisorbaudrate      115200

Resume Loader Settings
----------------------
identifier              {resumeloadersettings}
inherit                 {globalsettings}

Device options
--------------
identifier              {459d8028-7384-11e9-be04-d0509976b8c9}
description             Windows Setup
ramdisksdidevice        partition=C:
ramdisksdipath          \$WINDOWS.~BT\Sources\SafeOS\boot.sdi

Device options
--------------
identifier              {7d97a532-547d-11e5-a131-f9d2080e85a8}
description             Windows Recovery
ramdisksdidevice        unknown
ramdisksdipath          \Recovery\WindowsRE\boot.sdi

Device options
--------------
identifier              {85b68804-7385-11e9-8525-80c21444cd72}
description             Windows Recovery
ramdisksdidevice        partition=\Device\HarddiskVolume5
ramdisksdipath          \Recovery\WindowsRE\boot.sdi

 

Magically.... I have a firmware application for the usb! BOOTX64.efi does not get overwritten. However, if I clean the USB and perform the same command. BOOTX64.efi is written, back to original output of bcdedit with no firmware applications, if I then overwrite BOOTX64.efi and then run the same command again, BOOTX64.efi is overwritten.

 

EDIT: And that is called the prestige. Good night!

 

EDIT2: I forgot to say don't do this as you can destroy your whole installation.

 

Edited by apianti
  • Like 1
SoThOr
SoThOr
Posted
Posted
On 5/10/2019 at 5:33 AM, apianti said:

And are you really telling me how to use bcfg or bcdedit? Windows BCD only contains entries pertaining to windows boot manager and does nothing with EFI entries. It is not capable of editing EFI boot entries, however, it can chain load, though it doesn't always work. 

I agree with the part about the Windows BCD having nothing to do with EFI entries. The next part is where I think we start to disagree. It is unclear what you are referring to as "it" but Windows IS capable of editing EFI Boot entries and it IS possible to do this via bcdedit. Perhaps bcdboot was what you were referring to and if that is the case then I think I would agree with you but that was not mentioned until after the above quoted message. 

 

On 5/10/2019 at 7:47 AM, apianti said:

 bcdedit only reads from the BCD for entries.

bcdedit does read from EFI boot entries if you use either "ALL" or the "FIRMWARE" options for the /enum argument (or at minimum a cache copy of the entries that is created at boot). As pointed out in my previous posts my firmware likes to add extra Boot#### variables other than ones added manually or by installers and they appear with the bcdedit /enum FIRMWARE command. My evidence given in my previous post.

 

Maybe I am interpreting what you said incorrectly but these the reasons I decided to add my 2 cents.


Anyway, I think this is straying from what your initial point was. That using Clover at \EFI\BOOT\BOOTX64.efi is unsafe as Windows or potentially any other OS or bootloader could overwrite that file. Which I agree entirely.

 

I think I shall go back to lurking now.

apianti
apianti
Posted
Posted
9 minutes ago, SoThOr said:

I agree with the part about the Windows BCD having nothing to do with EFI entries. The next part is where I think we start to disagree. It is unclear what you are referring to as "it" but Windows IS capable of editing EFI Boot entries and it IS possible to do this via bcdedit. Perhaps bcdboot was what you were referring to and if that is the case then I think I would agree with you but that was not mentioned until after the above quoted message. 

 

bcdedit does read from EFI boot entries if you use either "ALL" or the "FIRMWARE" options for the /enum argument (or at minimum a cache copy of the entries that is created at boot). As pointed out in my previous posts my firmware likes to add extra Boot#### variables other than ones added manually or by installers and they appear with the bcdedit /enum FIRMWARE command. My evidence given in my previous post.

 

Maybe I am interpreting what you said incorrectly but these the reasons I decided to add my 2 cents.


Anyway, I think this is straying from what your initial point was. That using Clover at \EFI\BOOT\BOOTX64.efi is unsafe as Windows or potentially any other OS or bootloader could overwrite that file. Which I agree entirely.

 

I think I shall go back to lurking now.

 

No, actually neither is capable of creating EFI entries in the way you think. They both can create one entry, the one pointed to by {bootmgr} (previously bcdedit could only modify the entry but it seems that it creates it now as well if needed). The firmware entries are added by bootmgfw.efi to the BCD that is passed into the system for usage (through the registry) and to prevent not having a default loader has some setting to replace BOOTX64.efi (while apparently not properly enumerating the rest of the firmware entries). I'm going to turn off my notifications now. Because I am serious, I am not enjoying doing this anymore.

SoThOr
SoThOr
Posted
Posted
5 hours ago, apianti said:

 

No, actually neither is capable of creating EFI entries in the way you think. They both can create one entry, the one pointed to by {bootmgr} (previously bcdedit could only modify the entry but it seems that it creates it now as well if needed). The firmware entries are added by bootmgfw.efi to the BCD that is passed into the system for usage (through the registry) and to prevent not having a default loader has some setting to replace BOOTX64.efi (while apparently not properly enumerating the rest of the firmware entries). I'm going to turn off my notifications now. Because I am serious, I am not enjoying doing this anymore.

 

I didn't claim that bcdedit could create EFI boot entries. I said it could read and edit them. I realize bcdedit is a tool created for managing the Windows BCD however Microsoft has added the ability to read and modify EFI Boot entries also. I am not confusing BSD entries and EFI entries either. It might not be very well documented that it is able to modify EFI Boot entries but it can and I have used it previously to make modifications to EFI Boot entries.

 

Out of curiosity I tried to see if bcdedit could create EFI Boot entries and I managed to find a way to create EFI boot entries using bcdedit. It's a little bit of a hack but it is possible. Rather than posting here I decide to start a new thread. If anyone is interested they can read more about how here.

apianti
apianti
Posted
Posted

Siiiiiiiiiiiiiiiiiiiiiiiiiiiiigggggggggggggggggghhhhhhhhhhhhhhhh...................... You missed my point, it is not reading the EFI entries. It is reading the BCD from the registry, which was populated with firmware entries by bootmgfw.efi on boot. If I go into the registry and look at the BCD I have firmware entries there, yet none of them are displayed in bcdedit /enum all. Also as I said it can create one entry {bootmgr}, I'm pretty sure what you describe in the other topic is a bug (just like the enumeration one I am saying there is) not to mention that yes it includes the option data which can cause undefined behavior in whatever you created when launched... If it was able to create actual entries then you would be able to add an entry that is simply a firmware application, you cannot do this. The only way to edit EFI entries is to use the windows API. Windows applications and drivers can't even read or write nvram variables without a special certificate from microsoft (that you must request and provide reasons why you need to use nvram), and additionally being signed, having two special attributes, being run as an administrator or the system and that user has to have a special privilege. What you have described is actually an easy way for a rootkit to be installed, which completely defeats the purpose of all their restrictions on nvram access.

Logician
Logician
Posted
Posted

I have two MacOS installations -- is there a way to specify per-volume "config.plist" files so that a different configuration is automatically loaded without manually loading a new config in Options?  E.g., "config.plist" is tied to "High Sierra" and config2.plist is tied to "Mojave"?

Slice
Slice
Posted
Posted

This is just wrong idea.

All patches in config.plist are os version specific. No need to have different configs.

Or you want to have different GUI themes before choosing an OS?! Christmas for High Sierra and NewYear for Mojave?

arsradu
arsradu
Posted
Posted (edited)

Hi guys

 

I've just updated to 10.14.5 aaand...yeah, that issue with purple horizontal lines on first stage boot is there. Sad times... I'm guessing this is a bug on Apple's side. But I'm curious if anyone else has this issue. And if it's only with RX 580 or any other cards, too.

Edited by arsradu
Cyberdevs
Cyberdevs
Posted
Posted
9 minutes ago, arsradu said:

Hi guys

 

I've just updated to 10.14.5 aaand...yeah, that issue with purple horizontal lines on first stage boot is there. Sad times... I'm guessing this is a bug on Apple's side. But I'm curious if anyone else has this issue. And if it's only with RX 580 or any other cards.

Yeah I noticed that during the installation process on my RX 580 and tomorrow I’m gonna update my IvyBridge with R9 270X and let you know if the same issue happens or not.

  • Like 1
arsradu
arsradu
Posted
Posted
[mention=1303722]arsradu[/mention]
I just decided to install the update on the Ivy right now and the purple lines are also there <_ i guess there will be once the installation is done>

Well that sucks... so is it an Apple issue...? I haven’t tried the on-board graphics yet. If it occurs with that one too, well, I don’t know what to say anymore...
Cyberdevs
Cyberdevs
Posted
Posted
1 minute ago, arsradu said:

Well that sucks... so is it an Apple issue...? I haven’t tried the on-board graphics yet. If it occurs with that one too, well, I don’t know what to say anymore...

Yeah that sucks for sure, not only the flashing issue isn't resolved another issues appears which makes things even worse!

I might never reboot my hack ever again!! :D

 

Slice
Slice
Posted
Posted
On 5/13/2019 at 9:57 PM, Dr. Hurt said:

Why does the latest official Clover build have integrated exfat driver? It slows down the boot process by unnecessarily scanning my media partition.

May be ebuild.sh changed and I didn't notice the change in  

!ifndef NO_GRUB_DRIVERS
INF  Clover/FileSystems/GrubFS/src/EXFAT.inf	
#INF  Clover/FileSystems/GrubFS/src/NTFS.inf
!endif

Before this I always compiled with the key NO_GRUB_DRIVERS.

I will check next release.

 

  • Like 2
arsradu
arsradu
Posted
Posted

 

Guys, quick question: does the screenshot feature of Clover work only in the UI, or does it work in verbose mode, as well? Cause that would be really, really cool.

 

Right now, if you wanna screenshot a specific section of the verbose log, you have to take a picture with your cellphone or something and then mail it to yourself so you can see it on a bigger screen. And it usually comes out crooked and blurry. Which is not something you want, if you're planning on actually using that to debug something.

 

Just wondering if that would be possible (I'm guessing the answer is probably No, but just asking). :) 

 

Cyberdevs
Cyberdevs
Posted
Posted
5 minutes ago, arsradu said:

 

Guys, quick question: does the screenshot feature of Clover work only in the UI, or does it work in verbose mode, as well? Cause that would be really, really cool.

 

Right now, if you wanna screenshot a specific section of the verbose log, you have to take a picture with your cellphone or something and then mail it to yourself so you can see it on a bigger screen. And it usually comes out crooked and blurry. Which is not something you want, if you're planning on actually using that to debug something.

 

Just wondering if that would be possible (I'm guessing the answer is probably No, but just asking). :) 

I'm not sure if such feature exist or not (it probably does not) but I usually take videos of verbose mode which I can then view more clearly and find a certain section in slower playback.

arsradu
arsradu
Posted
Posted (edited)
11 minutes ago, Cyberdevs said:

I'm not sure if such feature exist or not (it probably does not) but I usually take videos of verbose mode which I can then view more clearly and find a certain section in slower playback.

 

Yeah, I don't think there is such a thing currently. I was wondering if that would even be possible to implement? Cause I've never seen it anywhere before.

 

And yeah, when there is fast moving text, I also usually take a video and then play it back frame by frame or in slow motion and such. But when I said blurry, I meant more like not in focus. I can rarely get a perfectly clear picture of the screen, with my phone, even if the text is not moving. The camera just doesn't wanna focus correctly on that text. It looks sharp enough. But when I check out the result, I struggle to understand what the hell is written there. :)) 

 

So that's why I thought maybe having the screenshot feature available while in verbose mode, would be really useful. :D But as you said, and as I suspect, that's probably not possible, or it would require more work to get it done, and it's just not worth it.

Edited by arsradu
msbc
msbc
Posted
Posted (edited)
19 hours ago, eSaF said:

Add me to the list of White Flash and then "Purple Lines" with the RX580 - don't know if it's an Apple issue though because I tried a cheapo Nvidia 710 card and the boot screen is without any anomalies as with the RX580.

Same here.

 

ASUS MAXIMUS  X HERO, I7-8700, RX580+UHD630

Edited by msbc
Slice
Slice
Posted
Posted
On 5/19/2019 at 12:13 PM, arsradu said:

 

Guys, quick question: does the screenshot feature of Clover work only in the UI, or does it work in verbose mode, as well? Cause that would be really, really cool.

 

Right now, if you wanna screenshot a specific section of the verbose log, you have to take a picture with your cellphone or something and then mail it to yourself so you can see it on a bigger screen. And it usually comes out crooked and blurry. Which is not something you want, if you're planning on actually using that to debug something.

 

Just wondering if that would be possible (I'm guessing the answer is probably No, but just asking). :) 

 

Nice wishes but it's impossible. When you see verbose text then Clover is out of the events horizon. When kernel took a drive then no our services are posiible.

I may recommend to see NVRAM for variable AAPL,panic-info where the log is written if the hardware nvram is supported.

  • Like 2
Sherlocks
Sherlocks
Posted
Posted (edited)

@Slice

long time no see.

can we consider smcverision 1/2/3? smcversion3 doesn't have REV/EPCI/RBR. 

FakeSMC force inject REV value right? can we just control datahub part to not relate FakeSMC rev?

Edited by Sherlocks
arsradu
arsradu
Posted
Posted (edited)

Hi guys,

 

Just so you know, downloading GNU gettext via the curl command in buildgettext.sh doesn't seem to work anymore. Probably server issues, probably something else. I only wanted to let you guys know about this issue in case you encounter it too.

 

 

1244520192_Screenshot2019-05-21at20_20_42.thumb.png.5fd64042185ac4f812af3ec6b8b35ae8.png

 

Download works fine from their website though. So, as a workaround, I just downloaded the archive manually, renamed it and placed it inside the src/tools/download folder.

 

Problem solved. :))

Edited by arsradu
  • Like 1
 Share
Go to topic listing
×
×
  • Create New...