Re: [darwinbuild] booting xnu 8G32
Hm, typically when I can't even get to the verbose logging I find that the issue is that the booter can't even find either the kernel or the kextcache. There shouldn't be any permissions issues at that stage, but generally booter + kernel + gets you to verbose output and then kext_cache is just about the first thing loaded once the kernel takes over. Perhaps the issue is that the kernel failed to load? Has anyone else had problems getting a home-rolled kernel to load like this? _Mark On Feb 2, 2006, at 10:53 AM, ritchie wrote:
On 06-02-06, at 1419 , Mark Pauley wrote:
What happens when you boot in verbose mode (hold down apple-v)? Perhaps you need to touch your /System/Library/Extensions directory, so you don't try to use the old kernel kext-cache with your new kernel?
I set it to boot in verbose mode in open firmware, but it doesn't even get that far. I may have to see if I can turn kernel logging or something on, to figure out exactly how far it's going. I'll try touching the /System/Library/Extensions, though I assumed that's what kextcache -c -K /newkernel did explicitly. thanks for the suggestions. have you booted to 8.4.1? I may try an install of 10.4.3 on an external disk and build the previous version to see if that works.
r.
On 06-02-06, at 1459 , Mark Pauley wrote:
Hm, typically when I can't even get to the verbose logging I find that the issue is that the booter can't even find either the kernel or the kextcache. There shouldn't be any permissions issues at that stage, but generally booter + kernel + gets you to verbose output and then kext_cache is just about the first thing loaded once the kernel takes over. Perhaps the issue is that the kernel failed to load?
I was thought about that, and was wondering if I needed to update BootX to handle a universal binary, but that doesn't explain why the ppc-only kernel doesn't boot, either. I will fiddle more with the kextcache stuff after lunch. I built BootX, but am not exactly sure what to do with the files it produces. I was careful to put the kernel back into the wheel group after copying it to /, since it seems to get changed to root,admin in the copying process. any other gotchas I should look for? best, r.
No BootX changes should be needed to use universal kernels or kexts What copying program did you use? root:admin is a very serious issue. All files produced by the xnu build should be owned by root:wheel, not root:admin [root@stargate]# kextload -t /System/Library/Extensions/ IOCDStorageFamily.kext kextload: extension /System/Library/Extensions/IOCDStorageFamily.kext appears to be valid kextload: extension /System/Library/Extensions/IOCDStorageFamily.kext is already loaded [root@stargate]# chown -R root:admin /System/Library/Extensions/ System.kext/PlugIns/IOKit.kext [root@stargate]# kextload -t /System/Library/Extensions/ IOCDStorageFamily.kext kernel extension /System/Library/Extensions/IOCDStorageFamily.kext has problems: Missing dependencies { "com.apple.iokit.IOStorageFamily" = "This dependency has dependencies that cannot be resolved" "com.apple.kpi.iokit" = "No valid version of this dependency can be found" } What's the output of "cd /System/Library/Extensions/System.kext && find . -ls"? Shantonu On Feb 2, 2006, at 11:19 AM, ritchie wrote:
On 06-02-06, at 1459 , Mark Pauley wrote:
Hm, typically when I can't even get to the verbose logging I find that the issue is that the booter can't even find either the kernel or the kextcache. There shouldn't be any permissions issues at that stage, but generally booter + kernel + gets you to verbose output and then kext_cache is just about the first thing loaded once the kernel takes over. Perhaps the issue is that the kernel failed to load?
I was thought about that, and was wondering if I needed to update BootX to handle a universal binary, but that doesn't explain why the ppc-only kernel doesn't boot, either. I will fiddle more with the kextcache stuff after lunch. I built BootX, but am not exactly sure what to do with the files it produces.
I was careful to put the kernel back into the wheel group after copying it to /, since it seems to get changed to root,admin in the copying process. any other gotchas I should look for?
best, r. _______________________________________________ darwinbuild mailing list darwinbuild@opendarwin.org http://www.opendarwin.org/mailman/listinfo/darwinbuild
On 06-02-06, at 1545 , Shantonu Sen wrote:
No BootX changes should be needed to use universal kernels or kexts
What copying program did you use? root:admin is a very serious issue. All files produced by the xnu build should be owned by root:wheel, not root:admin
the files were owned by root:wheel when finished building. I used cp to copy to /, at which point I re-grouped it in wheel.
What's the output of "cd /System/Library/Extensions/System.kext && find . -ls"?
everything there is owned by root:wheel, though I didn't muck with anything is System.kext when I installed the kernel, I _only moved the mach_kernel. however mark pauley's suggestion that the kernel isn't even being seen is leading somewhere. I was using the kswap.sh script (http://opendarwin.org/~jpm/naughty/darwin/kswap.sh) to install the kernel, but apparently it generates a boot-file variable that doesn't work on this machine (g5 dual2.7). if I copy the system- installed kernel: # cp /mach_kernel /mach_kernel.orig # chgrp wheel /mach_kernel.orig # kswap.sh --test mach_kernel.orig this doesn't boot. moving my custom kernel directly to /mach_kernel _does boot. I'm currently trying to figure out what an appropriate boot-file argument is for a g5. thanks for all your help. best, r.
What's the output of "nvram -p" after you run this kswap script? Or you can paste the output of:
sh -x kswap.sh --test mach_kernel.orig
In any event, be wary of shell scripts downloaded from the internet. ;-) Shantonu On Feb 2, 2006, at 12:57 PM, ritchie wrote:
On 06-02-06, at 1545 , Shantonu Sen wrote:
No BootX changes should be needed to use universal kernels or kexts
What copying program did you use? root:admin is a very serious issue. All files produced by the xnu build should be owned by root:wheel, not root:admin
the files were owned by root:wheel when finished building. I used cp to copy to /, at which point I re-grouped it in wheel.
What's the output of "cd /System/Library/Extensions/System.kext && find . -ls"?
everything there is owned by root:wheel, though I didn't muck with anything is System.kext when I installed the kernel, I _only moved the mach_kernel. however mark pauley's suggestion that the kernel isn't even being seen is leading somewhere. I was using the kswap.sh script (http://opendarwin.org/~jpm/naughty/darwin/ kswap.sh) to install the kernel, but apparently it generates a boot- file variable that doesn't work on this machine (g5 dual2.7). if I copy the system-installed kernel:
# cp /mach_kernel /mach_kernel.orig # chgrp wheel /mach_kernel.orig # kswap.sh --test mach_kernel.orig
this doesn't boot. moving my custom kernel directly to /mach_kernel _does boot. I'm currently trying to figure out what an appropriate boot-file argument is for a g5.
thanks for all your help.
best, r. _______________________________________________ darwinbuild mailing list darwinbuild@opendarwin.org http://www.opendarwin.org/mailman/listinfo/darwinbuild
On 06-02-06, at 1824 , Shantonu Sen wrote:
What's the output of "nvram -p" after you run this kswap script?
the boot-file variable is: first-boot/@0:3,mach_kernel.orig I was also booting off a fw disk, in which case the fw disk address was a big long mess. I read that some machines don't like the @0:#, instead requiring @0:0, but I'm not sure that makes sense for this particular case, since it's being copied directly from the boot- device variable: first-boot/@0:3,\\:tbxi perhaps boot-file needs to have some \'s or /'s preceding the filename? I haven't been able to find much info at all on the particulars of boot-file and different machines/os's. it seems like it's just a handy place to pass some info to the boot-loader, so perhaps I need to go diving in BootX? for now just copying my new kernel onto /mach_kernel and keeping a rescue os on a fw disk seems like a decent method.
In any event, be wary of shell scripts downloaded from the internet. ;-)
true enough. doesn't almost all of darwinbuild fall into that category? :) best regards, r.
Did you use the OS picker (by holding option) to select the FW drive? If so, the problem is that your boot-device and boot-file are point at different physical devices Use Startup Disk to pick the FW drive, boot from it once successfully, then run the script to change your kernel Shantonu On Feb 2, 2006, at 3:17 PM, ritchie wrote:
On 06-02-06, at 1824 , Shantonu Sen wrote:
What's the output of "nvram -p" after you run this kswap script?
the boot-file variable is: first-boot/@0:3,mach_kernel.orig
I was also booting off a fw disk, in which case the fw disk address was a big long mess. I read that some machines don't like the @0:#, instead requiring @0:0, but I'm not sure that makes sense for this particular case, since it's being copied directly from the boot- device variable: first-boot/@0:3,\\:tbxi
perhaps boot-file needs to have some \'s or /'s preceding the filename? I haven't been able to find much info at all on the particulars of boot-file and different machines/os's. it seems like it's just a handy place to pass some info to the boot-loader, so perhaps I need to go diving in BootX? for now just copying my new kernel onto /mach_kernel and keeping a rescue os on a fw disk seems like a decent method.
In any event, be wary of shell scripts downloaded from the internet. ;-)
true enough. doesn't almost all of darwinbuild fall into that category? :)
best regards, r. _______________________________________________ darwinbuild mailing list darwinbuild@opendarwin.org http://www.opendarwin.org/mailman/listinfo/darwinbuild
Perhaps check the permissions on the Extensions.mkext. Honestly, I would just touch /System/Library/Extensions, but it sounds like you're not even getting to that point. Are you running on ppc? You could try thinning the kernel, but the booter shouldn't care about what architectures are present. My guess is still that either the booter isn't being loaded properly or the booter can't load the kernel. Make sure to always use the ditto command when merging roots into your system, it will preserve permissions and resources etc. _Mark On Feb 2, 2006, at 11:19 AM, ritchie wrote:
On 06-02-06, at 1459 , Mark Pauley wrote:
Hm, typically when I can't even get to the verbose logging I find that the issue is that the booter can't even find either the kernel or the kextcache. There shouldn't be any permissions issues at that stage, but generally booter + kernel + gets you to verbose output and then kext_cache is just about the first thing loaded once the kernel takes over. Perhaps the issue is that the kernel failed to load?
I was thought about that, and was wondering if I needed to update BootX to handle a universal binary, but that doesn't explain why the ppc-only kernel doesn't boot, either. I will fiddle more with the kextcache stuff after lunch. I built BootX, but am not exactly sure what to do with the files it produces.
I was careful to put the kernel back into the wheel group after copying it to /, since it seems to get changed to root,admin in the copying process. any other gotchas I should look for?
best, r. _______________________________________________ darwinbuild mailing list darwinbuild@opendarwin.org http://www.opendarwin.org/mailman/listinfo/darwinbuild
Am 02.02.2006 um 19:59 schrieb Mark Pauley:
Hm, typically when I can't even get to the verbose logging [...]
The BootX coming with XPostFacto logs messages even before the kernel gets loaded if you hold down cmd-v at the boot chime. Dunno wether the standard BootX supports that.
[...] I find that the issue is that the booter can't even find either the kernel or the kextcache. There shouldn't be any permissions issues at that stage
To my experience, wrong ownership or permissions prevent the kernel from being loaded. Security risk blah blah ... ;-)
[...] then kext_cache is just about the first thing loaded once the kernel takes over.
To avoid trouble here, I usually simply remove the kext-cache: sudo rm /System/Library/Extensions.mkext Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
participants (4)
-
Mark Pauley
-
Markus Hitter
-
ritchie
-
Shantonu Sen