spakk, on 17 November 2012 - 12:15 AM, said:
These two kexts have the problem with "still wait for root device ....." adjusted to my system.
Good night
Hi!
The problem with my IDE system was the missing kexts for IDE drives (ApplePIIXATA.kext and other stuff).
With my Phenom II 965 system and SATA drives (correct kexts), it loaded, but paniced.
EDIT: The pic...
1. This is just an example of the messages I get. I get like thousands of those lines, will probably take a video soon...
2. IOStorageFamily.kext, again. I think it causes the panic.
NOTE: This is not with Spakk's kexts! Will try with them soon!
3. Here you can see my boot flags and other stuff related to the kernel, 11.4.0 as you can see.
EDIT2: Spakk's kexts: Loads maybe a little further (don't know)... Stuck on some kext loading, again. It appears to be a wrong version of IOStorageFamily.kext.
EDIT3:
So close, but still so far. Found out that after about 3 restarts the kext thingy fixed itself. New panic.
Quick googling and it seems that the error is somehow to related to HDD (or in this case USB-stick) failing. However, I don't know if thats the case, the stick works fine with other computers...
EDIT4: I can confirm it is not related to any specific HDD or usb-stick. Tried booting from the IDE-drive (with AppleVIAATA.kext or something, same panic:
Process 1 exec of /sbin/launchd failed, errno 86
EDIT5: Tried with launchd from SL 10.6.8, same panic. I think we need the Lion 10.7.4 launchd?
Heres the function that calls the panic, some coder could take a look:
load_init_program(proc_t p)
{
vm_offset_t init_addr;
int argc = 0;
uint32_t argv[3];
int error;
int retval[2];
/*
* Copy out program name.
*/
init_addr = VM_MIN_ADDRESS;
(void) vm_allocate(current_map(), &init_addr, PAGE_SIZE,
VM_FLAGS_ANYWHERE);
if (init_addr == 0)
init_addr++;
(void) copyout((caddr_t) init_program_name, CAST_USER_ADDR_T(init_addr),
(unsigned) sizeof(init_program_name)+1);
argv[argc++] = (uint32_t)init_addr;
init_addr += sizeof(init_program_name);
init_addr = (vm_offset_t)ROUND_PTR(char, init_addr);
/*
* Put out first (and only) argument, similarly.
* Assumes everything fits in a page as allocated
* above.
*/
if (boothowto & RB_SINGLE) {
const char *init_args = "-s";
copyout(init_args, CAST_USER_ADDR_T(init_addr),
strlen(init_args));
argv[argc++] = (uint32_t)init_addr;
init_addr += strlen(init_args);
init_addr = (vm_offset_t)ROUND_PTR(char, init_addr);
}
/*
* Null-end the argument list
*/
argv[argc] = 0;
/*
* Copy out the argument list.
*/
(void) copyout((caddr_t) argv, CAST_USER_ADDR_T(init_addr),
(unsigned) sizeof(argv));
/*
* Set up argument block for fake call to execve.
*/
init_exec_args.fname = CAST_USER_ADDR_T(argv[0]);
init_exec_args.argp = CAST_USER_ADDR_T((char **)init_addr);
init_exec_args.envp = CAST_USER_ADDR_T(0);
/*
* So that mach_init task is set with uid,gid 0 token
*/
set_security_token(p);
if (KERN_patcherOpts & OPT_PATCHER_DEBUG)
dump_patcher_opts();
error = execve(p,&init_exec_args,retval);
if (error)
panic("Process 1 exec of %s failed, errno %d",
init_program_name, error);
}
Also, here is something kinda positive from Wikipedia:
Quote
launchd launchd has two main tasks. The first is to boot the system, and the second is to load and maintain services.
Here is a simplified view of the Mac OS X Tiger system startup on a PowerPC Mac (on an Intel Mac, EFI replaces Open Firmware and boot.efi replaces BootX):
1. Open Firmware activates, initializes the hardware, and then loads BootX.
2. BootX loads the kernel, spins the pinwheel cursor, and loads any needed kernel extensions (kexts).
3. The kernel loads launchd.
4. launchd runs /etc/rc, scans through /System/Library/LaunchAgents and /Library/LaunchDaemons and acts on the plists as needed, and starts the login window.
So, about 50% boot!
Sign In
Create Account
42
