[GUIDE] Scripted Yosemite/Mavericks Install on Gigabyte Mobos

[zoro2]

You MUST run the DSDT patcher on the system you are installing onto. A DSDT from a G4 will not help you at all I may even cause more problems.

I want to be clear here, so I can understand your point. The drive in question is external and either eSata or USB. As eSata I boot my SNL system on it. But when I could do nothing else with it, I Was able to allow my G4, which is running leopard, to run the script from the beginning of this thread, pointing it at the external drive that I now boot on with my SNL set up. Same drive, in my HT, it's booting as main drive via eSata. With the G4 (Leo) I am mounting it via USB and running the script on it, including DSDT Patch.

 

I was NOT booting this on a G4. Have I understood your point, or have I Missed it?

 

Thanks MAJ for the tip on the extras folder. I just reloaded the whole SNL system on that drive. You are right, there is no Extras folder this time. And, sound works now.

 

But wait, there's more. Not quite celebrating yet. I made sure to not check any extra data to bring over, and yet, even though I can log into my accounts, I have no admin account now. So I Cant update my system or do anything which requires a password.

 

There must be a way to do this in the terminal?

[LocusOfControl]

As far as I know there is no sound configuration settings in bios. And besides, it has working sound when I boot to the RAID (older working) drive.

 

You have problems with your bios being reset due to the CMOS reset problem which can be fixed with a correct DSDT

for your board. This means that everything will be reset to default values whatever they are every time you boot until

you fix it - a small job

 

The correct DSDT for your UD4 is one supporting a UD4 bios assuming the drive you are booting from is attached

to the UD4. As you rightly stated previously, you can't boot this drive containing SL on a G4

 

The sound is controlled in your bios by Azalia codec in integrated peripherals ( as stated in your manual ). It may not be

the cause of your problem but you should check its value

 

edit: wrt to DSDT tutorial - I posted the link previously - look at point number 1

[digital_dreamer]

<snip>

I was NOT booting this on a G4. Have I understood your point, or have I Missed it?

 

Thanks MAJ for the tip on the extras folder. I just reloaded the whole SNL system on that drive. You are right, there is no Extras folder this time. And, sound works now.

RE DSDT patch

Point missed. Although you are not booting the install on the G4, the DSDT patch is being created on the G4. Not good. This results in a DSDT file containing hardware information gathered from the G4, not your target hackintosh. So, only run the DSDT patcher on the hackintosh. That way it will gather the correct hardware information.

 

I hope you meant there is no "Extensions" folder, rather than no Extras folder.

 

MAJ

[zoro2]

RE DSDT patch

Point missed. Although you are not booting the install on the G4, the DSDT patch is being created on the G4. Not good. This results in a DSDT file containing hardware information gathered from the G4, not your target hackintosh. So, only run the DSDT patcher on the hackintosh. That way it will gather the correct hardware information.

 

I hope you meant there is no "Extensions" folder, rather than no Extras folder.

 

MAJ

Yes, the Extra folder is there, sorry to have misspoken. And point taken, running the DSDT from a G4 was a a mistake. THe good news then is I probably do not have a CMOS restart bug. IT has worked since properly running the DSDT patch as you long ago suggested. THanks.

 

Now what I have to do is see how to get an admin account set up. Right now there is not longer any admin. That means I Can't upgrade or install anything as the system wants a password and a name that I don't have. How that happened I don't know. I was reading that booting on the install disk would allow the utility on the install disk to change my admin password. Obviously this would have to come at a point where the script allowed the install disk tom mount and run.

 

Thanks LocusOfControl, I will investigate the tutorial. I very much appreciate your mentioning it.

[LocusOfControl]

THe good news then is I probably do not have a CMOS restart bug. IT has worked since properly running the DSDT patch as you long ago suggested. THanks.

 

The CMOS reset bug is not a bug in your bios, rather it is caused by an 'incorrect' setting in your DSDT which causes

your CMOS to be reset on rebooting

 

The solution is either fix your DSDT yourself, or obtain a patched DSDT from somewhere else for your board.

You have done the latter which is why it is fixed, I would suggest you leave it alone now (and make a backup if

everything is working)

 

What happens if you type sudo -s followed by return without entering a password?

[zoro2]

The CMOS reset bug is not a bug in your bios, rather it is caused by an 'incorrect' setting in your DSDT which causes

your CMOS to be reset on rebooting

 

The solution is either fix your DSDT yourself, or obtain a patched DSDT from somewhere else for your board.

You have done the latter which is why it is fixed, I would suggest you leave it alone now (and make a backup if

everything is working)

 

What happens if you type sudo -s followed by return without entering a password?

THanks, I understand now. And it is great that it is not doing that anymore. OR I guess one could argue that I am not doing that anymore (setting it up incorrectly). ANyway...

 

I am now in the old RAID setup reading this and responding. I will reboot and test as you ask.

 

To be as clear about the situation as possible;

1. When I boot I have the same logging into accounts as I had before I reinstalled the system from the SNL Apple install disk.
   
2. However, they were Admin accounts, more than one I think was an admin account, a problem left over from the way I set this up. When you don't have it migrate you old disks over on set up, naturally is sets up a new admin account. LAter when you do migrate over your old disks, still set as admin, you end up with many admin accounts. THey had the same pass so it worked.
   
3. Now, all those accounts are still there. I Can still log into the accounts. However, in the system preferences/Accounts menu, all shown accounts are now shown as "Standard". Ther are no Admin accounts anymore (shown.
   
4. The lock is on so when I click the lock to make changes it gives me a blank user name and blank password dialog to open the lock. Using my login account name and myy old password are rejected as incorrect.
   

 

Of course I cant update SNL to 10.6.3 either or make any other admin pass required changes as I Cant get in.

Worse, checking security my firewall is turned off allowing any connection in. And it is also locked so I Cant cahnge that setting eithyer. And taht is why I am communicating now from the working and firewall protected RAID drive.

 

I will reboot and check as you asked.

 

As an outside chance, I was thinking of temporarily changing this account name I am working on in RAID, the admin account. Then using migration assistant to pull in the old admin account. After that I Could bot safely again and like the last migration of that admin account, not really used at this point.

 

Hopfully there is a UNIX command that will allow me to find out how to change one of the accounts back into an admin account. I tried running the installer again via the script as some other threads suggested resetting the password from the utility on the installer disk. But I Cant really do that as you probably already know, the installer runs just as the installer, there is no utility available from this script (yet) for changing the admin password.

[Sidewinder33]

Hey Guys,

Ive been reading over the tutorial and about 40 pages of the thread so far but I had some questions I havent seen come up, probably because they are a bit stupid.

 

When rebooting for the first time where the -v arch=i386 is used at the prompt in the next section it says to boot into single user mode using the -s to prevent some post installation stuff for snow leopard, does that mean simply type -s arch=i386? Or is it a matter of booting using -v then entering single user mode after that at some point?

 

My next question, I'm very new to coding so I was just poking around at some of the files just to see what was in them and I happened across the huge file of gfx card kexts. Which go me thinking do I need to manually go in after the installation and select my card kext or is is selected by the script once the computer identifies the card?

 

Thank you for any help, I hope to get started on this next week (waiting on parts to arrive) I may/probably will have more questions, but I'll do my best to scour the thread first.

Jeff

[LocusOfControl]

THanks, I understand now. And it is great that it is not doing that anymore. OR I guess one could argue that I am not doing that anymore (setting it up incorrectly). ANyway...

 

 

[*]The lock is on so when I click the lock to make changes it gives me a blank user name and blank password dialog to open the lock. Using my login account name and myy old password are rejected as incorrect.

 

Of course I cant update SNL to 10.6.3 either or make any other admin pass required changes as I Cant get in.

Worse, checking security my firewall is turned off allowing any connection in. And it is also locked so I Cant cahnge that setting eithyer. And taht is why I am communicating now from the working and firewall protected RAID drive.

 

I will reboot and check as you asked.

 

As an outside chance, I was thinking of temporarily changing this account name I am working on in RAID, the admin account. Then using migration assistant to pull in the old admin account. After that I Could bot safely again and like the last migration of that admin account, not really used at this point.

 

Hopfully there is a UNIX command that will allow me to find out how to change one of the accounts back into an admin account. I tried running the installer again via the script as some other threads suggested resetting the password from the utility on the installer disk. But I Cant really do that as you probably already know, the installer runs just as the installer, there is no utility available from this script (yet) for changing the admin password.

 

You shouldn't need to reboot to do sudo -s

 

Why do you want to run migration assistant given all the trouble you had with it in the past?

 

In the accounts manager in system preferences have you tried using userid=root password=blank to unlock the

padlock (blank means empty, nothing ie do not type anything)

 

what did it do?

 

you should not need to reboot

[Josvdp]

I have used the migration assistant after installing before and I can't really advise it. In my case, it caused a lot of trouble like bonjour not properly working and stuff like that.

 

It's not that much of a hassle to just copy your files.

[LocusOfControl]

Hey Guys,

Ive been reading over the tutorial and about 40 pages of the thread so far but I had some questions I havent seen come up, probably because they are a bit stupid.

 

When rebooting for the first time where the -v arch=i386 is used at the prompt in the next section it says to boot into single user mode using the -s to prevent some post installation stuff for snow leopard, does that mean simply type -s arch=i386? Or is it a matter of booting using -v then entering single user mode after that at some point?

 

My next question, I'm very new to coding so I was just poking around at some of the files just to see what was in them and I happened across the huge file of gfx card kexts. Which go me thinking do I need to manually go in after the installation and select my card kext or is is selected by the script once the computer identifies the card?

 

Thank you for any help, I hope to get started on this next week (waiting on parts to arrive) I may/probably will have more questions, but I'll do my best to scour the thread first.

Jeff

 

Hi Jeff

 

Yes you would type -v arch=i386 -s on one line, the -v is just verbose mode which shows you what is happening during

boot

 

So the above line would just tell SL to boot in single user 32 bit mode and display the boot output verbosely

 

If your graphics card is supported then it should be selected automatically, what isn't needed or can't be supported

wont be loaded

 

 

 

 

I have used the migration assistant after installing before and I can't really advise it. In my case, it caused a lot of trouble like bonjour not properly working and stuff like that.

 

It's not that much of a hassle to just copy your files.

 

ditto, when I moved from Leopard to SL

As stated before CC is safer

[Sidewinder33]

Hi Jeff

 

Yes you would type -v arch=i386 -s on one line, the -v is just verbose mode which shows you what is happening during

boot

 

So the above line would just tell SL to boot in single user 32 bit mode and display the boot output verbosely

 

If your graphics card is supported then it should be selected automatically, what isn't needed or can't be supported

wont be loaded

 

Ah thank you for the explanation. I can't wait to give this a shot.

[zoro2]

Why do you want to run migration assistant given all the trouble you had with it in the past?

I have used the migration assistant after installing before and I can't really advise it. In my case, it caused a lot of trouble like bonjour not properly working and stuff like that.

 

It's not that much of a hassle to just copy your files.

Point taken.

 

You shouldn't need to reboot to do sudo -s ... you should not need to reboot

Still here .. I had a separate matter that took me away for a bit. I did use sudo -s here on this terminal/disk.

 

But this isn't the problem. I have booted to the RAID Leopard install now. Here on this boot I see my accounts, just for this boot. I can't see the other disk accounts unless I boot into that disk. Which is why I was wondering why I wouldn't need to reboot before doing this? Not arguing, if you say it I will do it, just not understanding.

 

The following code is what I get from the terminal in this good RAID boot: Please note, in this boot I can unlock the files and use full admin privileges. This disk seems not messed up.

 

 metheuser $ sudo -s
Password: (given and accepted)
bash-3.2#

In the accounts manager in system preferences have you tried using userid=root password=blank to unlock the

padlock (blank means empty, nothing ie do not type anything)

 

what did it do?

I did not think of that. I will wait a few for any response to this, then I will reboot and try that, USERID is root and pass is empty.

[knightprozac]

I've got an unusual question that I'm not sure anyone will be able to answer. I've done some searching myself but been unable to find info.

 

I've been trying to get TV-out on my 4890 for SL. Since the TV-out port is only recognised by windows I bought an Apple DVI to video adapter. The adapter works fine on my G5 but doesn't seem to work on my hackintosh for some reason even though the ports appear to be DVI-I and not DVI-D.

 

Does anyone know why it's not working or any other ways of getting TV-out on my Mac side?

[LocusOfControl]

 metheuser $ sudo -s
Password: (given and accepted)
bash-3.2#

 

Doesn't this give you your answer then?

 

The reason you don't know the root password (admin) is because you don't have one

 

You can set the root password to whatever you want ie

 

bash-3.2#passwd root

 

Your next move should be obvious...

 

hint: go to accounts in system prefs

 

edit : ie accounts in system pref after booting into SL

[zoro2]

Doesn't this give you your answer then?

The reason you don't know the root password (admin) is because you don't have one

You can set the root password to whatever you want ie

bash-3.2#passwd root

Your next move should be obvious...

hint: go to accounts in system prefs

edit : ie accounts in system pref after booting into SL

OK, I guess I have not understood this so it isn't that obvious. I have read about Admin and root being similar but not the same. Thus far I have not looked at root.

 

What you are saying is that on this working RAID system, I can input sudo - s (current admin password) then after bash-3.2# I can put in passwd root.

 

Sorry, this is really a new concept, following the Apple Developers Page:

 

Mac OS X v10.5

From the Finder's Go menu, choose Utilities.
Open Directory Utility.
Click the lock in the Directory Utility window.
Enter an administrator account name and password, then click OK.
Choose Enable Root User from the Edit menu.
Enter the root password you wish to use in both the Password and Verify fields, then click OK.

Did this just now. I have a root user ID then. I will now try the reboot and see what happens.

 

ADDED: OK, back now. No luck on the other drive. Yes I Now have a root password, although not a root ID. I assume the root ID is "root"?

 

I now have "Other" added to this value for log in privileges. It accepts the Root password I put in last. But the target disk does exactly the same as before. I cannot get in with the new root values.

 

---------------

Gatherd data from target external boot drive:

 

sudo -s

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

Password:

Sorry, try again.

Password:

zoro2 is not in the sudoers file. This incident will be reported.

zoro2-Mac-Pro:~ zoro2 $

---------------

 

Weird, reported to whom? Definitely open to suggestions here.

 

 

ADDED: There is a thread, here and here (this has some outdated info as Netinfo Manager appears to be no longer a part of 10.5 and above. THis is referenced here) on how to edit a suduers file using visudo. I am not going to mess things up without further feedback, but would this be a good direction? - Thanks

 

ADDED: I am not at all clear about all of this. I enterd the root password as you sugested, but I don't seem to need it. Am I reading the following sudoers contents correctly, that;

# Same thing without a password
# %wheel	ALL=(ALL)	NOPASSWD: ALL

Means a password actually does not matter? Not good if true. Here is the contents of suduers;

 

Mac-Pro:~ zoro2$ sudo cat /etc/sudoers 
Password:
# sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the sudoers man page for the details on how to write a sudoers file.
#

# Host alias specification

# User alias specification

# Cmnd alias specification

# Defaults specification
Defaults	env_reset
Defaults	env_keep += "BLOCKSIZE"
Defaults	env_keep += "COLORFGBG COLORTERM"
Defaults	env_keep += "__CF_USER_TEXT_ENCODING"
Defaults	env_keep += "CHARSET LANG LANGUAGE LC_ALL LC_COLLATE LC_CTYPE"
Defaults	env_keep += "LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME"
Defaults	env_keep += "LINES COLUMNS"
Defaults	env_keep += "LSCOLORS"
Defaults	env_keep += "SSH_AUTH_SOCK"
Defaults	env_keep += "TZ"
Defaults	env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"
Defaults	env_keep += "EDITOR VISUAL"

# Runas alias specification

# User privilege specification
root	ALL=(ALL) ALL
%admin	ALL=(ALL) ALL

# Uncomment to allow people in group wheel to run all commands
# %wheel	ALL=(ALL)	ALL

# Same thing without a password
# %wheel	ALL=(ALL)	NOPASSWD: ALL

# Samples
# %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom
# %users  localhost=/sbin/shutdown -h now

[LocusOfControl]

 

 

What I was suggesting was

 

Boot into SL

 

Problem you say you do not have an admin account to do anything requiring system privileges?

 

You will always have an admin account called root, it just so happens it doesn't yet have a password

(unless you set it earlier and forgot it)

 

when you do

 

metheuser $ sudo -s

Password: (given and accepted)

bash-3.2#

 

you gained root access by doing sudo -s (and there was no password), thus you have admin privileges in that terminal window. root (also called superuser) is an admin account, it has the power to do anything that is legal

with impunity

 

By doing this you also proved that root had no password set originally

 

Having gained root access you can set your root password (or anybody else's) to whatever you want

 

The prompt bash-3.2# signifies the root user's command line

 

If the above does NOT work

a ) you have either forgotten the root password

b ) you have somehow overwritten it

 

 

but you didn't need to get root in a terminal window..., it was just a quick test to see if the root account had its

password set

 

since I also suggested going to accounts, you could click on the padlock and enter name=root and leave the password blank as there was no password set

 

You would then be free to modify your account, or create 100's of new admin accounts because your are logged in as root etc

 

PS

 

I never suggested editing any files, do that at your own risk

[zoro2]

What I was suggesting was

 

Boot into SL

 

Problem you say you do not have an admin account to do anything requiring system privileges?

 

You will always have an admin account called root, it just so happens it doesn't yet have a password

(unless you set it earlier and forgot it)

 

when you do

 

metheuser $ sudo -s

Password: (given and accepted)

bash-3.2#

 

you gained root access by doing sudo -s (and there was no password), thus you have admin privileges in that terminal window. root (also called superuser) is an admin account, it has the power to do anything that is legal

with impunity

 

By doing this you also proved that root had no password set originally

 

Having gained root access you can set your root password (or anybody else's) to whatever you want

 

The prompt bash-3.2# signifies the root user's command line

 

If the above does NOT work

a ) you have either forgotten the root password

b ) you have somehow overwritten it

 

 

but you didn't need to get root in a terminal window..., it was just a quick test to see if the root account had its

password set

 

since I also suggested going to accounts, you could click on the padlock and enter name=root and leave the password blank as there was no password set

 

You would then be free to modify your account, or create 100's of new admin accounts because your are logged in as root etc

 

PS - I never suggested editing any files, do that at your own risk

 

You are correct in what you say, however it is not taking. Yes, it was at bash-3.2#. But I used the passwd root as suggested and put in a root password. I wrote it down and it seemed to have taken. But as I have not been able to gain access with any method discussed, I tried two other times to change the password just to get one to stick. Each time I am writing them down.

 

Just now I tried (logged into SNL) in the Terminal. $ passwd root

 

This gave me the following. It looked like it accepted my password, the I put in the new password, then put in the new password a second time to confirm it. Then it gave me a complaint about a shared cache file and said I have an authentication token failure.

 

$ passwd root

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

Changing password for root.

Old Password:

New Password:

Retype New Password:

passwd: authentication token failure

 

What is that?

 

And, no I Can't click on the lock and type root for the user and blank password field, or any of the root passwords I thought I had entered preciously. Yes, there is still no admin account on this boot, but there are three bootable accounts. Root appears to have accepted the password, but has a token failure. Worse, it complains that I am not in the sudoers contents. Which seems crazy as it is my computer and of course I would be in the sudoers contents...

 

Thoughts? THanks.

 

ADDED: I just booted back to my Leopard RAID drive. sudi -s and my login pass gives the empty bash-3.2# reference. It seems that in OSX if I Have root access in one account, I would have it in every account. But it seems not to be so? I just reverified that nothing I try with the boot disk with no admin accounts will allow me in to the admin or the root level. Yes, as you said this is at bash-3.2# from sudo -s on this raid drive, but none of your suggestions will take when booted back to the no admin drive.

 

I even tried the sudo update_dyld_shared_cache -force but that did no good that Ic could see.

 

Sigh, thanks for all your time. I am tired. Maybe some sleep will make this more clear to me.

[LocusOfControl]

You are correct in what you say, however it is not taking. Yes, it was at bash-3.2#. But I used the passwd root as suggested and put in a root password. I wrote it down and it seemed to have taken. But as I have not been able to gain access with any method discussed, I tried two other times to change the password just to get one to stick. Each time I am writing them down.

 

Just now I tried (logged into SNL) in the Terminal. $ passwd root

 

This gave me the following. It looked like it accepted my password, the I put in the new password, then put in the new password a second time to confirm it. Then it gave me a complaint about a shared cache file and said I have an authentication token failure.

 

$ passwd root

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

Changing password for root.

Old Password:

New Password:

Retype New Password:

passwd: authentication token failure

 

What is that?

 

And, no I Can't click on the lock and type root for the user and blank password field, or any of the root passwords I thought I had entered preciously. Yes, there is still no admin account on this boot, but there are three bootable accounts. Root appears to have accepted the password, but has a token failure. Worse, it complains that I am not in the sudoers contents. Which seems crazy as it is my computer and of course I would be in the sudoers contents...

 

Thoughts? THanks.

 

ADDED: I just booted back to my Leopard RAID drive. sudi -s and my login pass gives the empty bash-3.2# reference. It seems that in OSX if I Have root access in one account, I would have it in every account. But it seems not to be so? I just reverified that nothing I try with the boot disk with no admin accounts will allow me in to the admin or the root level. Yes, as you said this is at bash-3.2# from sudo -s on this raid drive, but none of your suggestions will take when booted back to the no admin drive.

 

I even tried the sudo update_dyld_shared_cache -force but that did no good that Ic could see.

 

Sigh, thanks for all your time. I am tired. Maybe some sleep will make this more clear to me.

 

try typing su -

enter the password for root - whichever one works is the correct one - remember it!

 

On the accounts window, click on padlock

use user=root password= the password I told you to remember

 

does that work?

 

Forget your Leopard account, that is a different machine. Root on that is not the same as root on your SL account

nor are any other accounts. Concentrate on fixing your SL account

[zoro2]

try typing su -

enter the password for root - whichever one works is the correct one - remember it!

 

On the accounts window, click on padlock

use user=root password= the password I told you to remember

 

does that work?

 

Forget your Leopard account, that is a different machine. Root on that is not the same as root on your SL account

nor are any other accounts. Concentrate on fixing your SL account

No, it is still not working. Staying only on teh SNL machine from now on. THe problem is the terminal starts with the error:

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

I get the idea that this line should not be popping up (thrice) on the terminal just by opening the terminal.

 

I have tried

sudo update_dyld_shared_cache -force

but it apparently makes no difference.

 

afaik the only way I have proven that there is no password at root level is from the other machine. When I try SU and every password I wrote down Termainl responds "Sorry, try again". When I try "passwd root" (and try a new password) I get

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

and then "authentication token failure"

[LocusOfControl]

No, it is still not working. Staying only on teh SNL machine from now on. THe problem is the terminal starts with the error:

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

I get the idea that this line should not be popping up (thrice) on the terminal just by opening the terminal.

 

I have tried

sudo update_dyld_shared_cache -force

but it apparently makes no difference.

 

afaik the only way I have proven that there is no password at root level is from the other machine. When I try SU and every password I wrote down Termainl responds "Sorry, try again". When I try "passwd root" (and try a new password) I get

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

and then "authentication token failure"

 

 

can you repeat what you did previously

 

metheuser $ sudo -s

Password: (given and accepted)

bash-3.2#

 

using either a blank password or your own password

 

if yes set the root password from that root terminal to something then try the accounts padlock with the new

root password

 

If not unless you can install the developer tools from your SL dvd I think you are stuck unless

anyone else can suggest something

[zoro2]

can you repeat what you did previously

 

metheuser $ sudo -s

Password: (given and accepted)

bash-3.2#

 

using either a blank password or your own password

 

if yes set the root password from that root terminal to something then try the accounts padlock with the new

root password

 

If not unless you can install the developer tools from your SL dvd I think you are stuck unless

anyone else can suggest something

No, it always says on this drive that; "... is not in the sudoers file. This incident will be reported."

 

I think we are stuck. Maybe running the DD script a couple times from the other drive, trying the various rebuild cache options? It sound like the caches are messed up.

 

Please be aware, this machine is still running the installed SNL 10.6. I have not run the updater to 10.6.2 because I have no access privileges to change anything. I don't know if that helps but, FWIW.

 

THanks.

[LocusOfControl]

No, it always says on this drive that; "... is not in the sudoers file. This incident will be reported."

 

I think we are stuck. Maybe running the DD script a couple times from the other drive, trying the various rebuild cache options? It sound like the caches are messed up.

 

Please be aware, this machine is still running the installed SNL 10.6. I have not run the updater to 10.6.2 because I have no access privileges to change anything. I don't know if that helps but, FWIW.

 

THanks.

 

 

OK - just remembered, I had a similar problem once

 

This WILL work

 

 

You will need to reboot into SL in single user mode

 

Boot to chameleon and hit tab until you get to the black screen showing the chameleon boot options

Select the SL drive

At the command prompt type , followed by return

 

-v arch=i386 -s

 

This will boot a bit slower than normal

 

eventually it will stop at the root hash prompt

 

You will see two commands

 

/sbin/fsck -fy

/sbin/mount -uw /

 

 

first type in /sbin/fsck -fy then return - this will check your filesystem and may take a few minutes

when done type

 

/sbin/mount -uw /

 

This will mount the filesystem so you can do stuff

 

when done type passwd root

 

you will be prompted to enter a new root password twice - do this then write it down

 

You will now DEFINITELY have a root password - Remember it!!!

 

when done type exit to continue booting to desktop

 

You should now be able to open padlocks with user id =root and your new password

[hollyend]

Hi everyone can I first say thanks to DD

I have created my first Hackintosh using the guide and the GA-EX58-UD5 with 2.6 920 i7 and all works well however, the 1TB WD green hard drive has a constant Click every 2 or 3 seconds unless the system is tasked. Question: has anyone noticed this? Is it just my build? Is there a fix? any help would be great.

[LocusOfControl]

Hi everyone can I first say thanks to DD

I have created my first Hackintosh using the guide and the GA-EX58-UD5 with 2.6 920 i7 and all works well however, the 1TB WD green hard drive has a constant Click every 2 or 3 seconds unless the system is tasked. Question: has anyone noticed this? Is it just my build? Is there a fix? any help would be great.

 

 

I haven't noticed anything with a 1TB WD Black HD

[zoro2]

OK - just remembered, I had a similar problem once

 

This WILL work

 

 

You will need to reboot into SL in single user mode

 

Boot to chameleon and hit tab until you get to the black screen showing the chameleon boot options

Select the SL drive

At the command prompt type , followed by return

 

-v arch=i386 -s

 

This will boot a bit slower than normal

 

eventually it will stop at the root hash prompt

 

You will see two commands

 

/sbin/fsck -fy

/sbin/mount -uw /

 

 

first type in /sbin/fsck -fy then return - this will check your filesystem and may take a few minutes

when done type

 

/sbin/mount -uw /

 

This will mount the filesystem so you can do stuff

 

when done type passwd root

 

you will be prompted to enter a new root password twice - do this then write it down

 

You will now DEFINITELY have a root password - Remember it!!!

 

when done type exit to continue booting to desktop

 

You should now be able to open padlocks with user id =root and your new password

Not yet. I printed your last post and booted in single user. Result:

 

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

 

/sbin/fsck -fy

/sbin/mount -uw /

 

#root: (TYPING:) /sbin/fsck -fy

-sh: /sbin/fsck: no such file or directory

 

#root: (TYPING:) /sbin/mount -uw /

root_device on / (hfs. local. read-only, journaled)

devfs on / dev(devfs. local. nobrowse

 

#root:

 

Unless I have misunderstood and when it prompts "#root:" is where I only need put in a password, it did not work.

 

Why is the following line appearing so aften?

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

I have never seen it before and it would seem to be a part of this problem?

 

Ongoing thanks.

 

Hi everyone can I first say thanks to DD

I have created my first Hackintosh using the guide and the GA-EX58-UD5 with 2.6 920 i7 and all works well however, the 1TB WD green hard drive has a constant Click every 2 or 3 seconds unless the system is tasked. Question: has anyone noticed this? Is it just my build? Is there a fix? any help would be great.

I have a 1 gig Fantom Green Drive, external. It runs eSata or USB and it does not click.