Re: Booting alternative kernels from primary disk?
Re: Booting alternative kernels from primary disk?
- Subject: Re: Booting alternative kernels from primary disk?
- From: Josh de Cesare <email@hidden>
- Date: Thu, 16 Jan 2003 08:32:40 -0800
Mark,
Here's what I do after testing a kernel that did not work...
Reboot, and stop at Open Firmware (hold CMD-OPT-O-F). Then I change
the boot-file parameter to point at my back up kernel; usually
/mach_kenrel.orig. Then boot the machine, fix the kernel and clear
boot-file parameter.
In OF type:
printenv boot-device
This will show the path to BootX; usually hd:9,\\:tbxi.
The important thing to note here, is the partition number (9) and the
path to the disk (hd:).
When setting the boot-file use the same path and partition number,
but put in the new kernel name at the end.
setenv boot-file hd:9,mach_kernel.orig
To continue booting type:
boot
After the machine has booted in terminal or on the console at root,
fix /mach_kernel and clear the boot-file with the nvram command:
nvram boot-fille=""
What do you do if you mess up a boot driver on the disk? The
only thing I have found is to boot off of a different partition and
replace it with the original one. This can be done from single user
off of an install CD.
Here's the other way I do kernel or driver development...
Net boot everything. It does require two machine and you will need a
DHCP server on your network. First enable tftpd on your build
machine. Copy /usr/standalone/ppc/bootx.xcoff to your tftpboot
directory, usually /private/tftpboot. Make a link in
/private/tftpboot to the build results of your xnu build and call is
something like mach_kernel.test. You will also need to make an mkext
to include all the important drivers. You will need a directory will
all the drivers from the target build of the OS, I assume below that
they are the same as the build machine.
kextcache -lna ppc -m /private/tftpboot/mach_kernel.test.mkext
/System/Library/Extensions
The mkext name must be <kernel-name>.mkext
Now the target machine needs to be configured. Set the
boot-device to point over the network to BootX, and the boot-file to
point at the kernel. Be sure to fill in the IP address of your build
machine.
setenv boot-device enet:12.34.56.78,bootx.xcoff
setenv boot-file enet:12.34.56.78,mach_kernel.test
At this point the machine should be able to boot, by finding
BootX and the kernel and mkext, but it will not know what to do about
the root disk. Set boot-args to point back at the disk. Normally,
if it gets to single user, I'm done, so I include -s, and debug=0x14e
in case it doesn't.
setenv boot-args -s debug=0x14e rd=*hd:9
Once all the parameters are set type sync-nvram to flush them out.
If the boot does not make it all the way through BootX, OF will not
flush them out, and you will have to type it all again.
As you rebuild new kernel, or change drivers (and rebuild the
mkext) on your build machine all you need to do to test the new stuff
is reboot the test machine. Good luck.
Josh
At 6:27 AM -0800 1/16/03, Mark Grimes wrote:
"Before you install the new kernel, make a copy of your original
kernel. When things fail you can always copy the original kernel back
by booting from a different disk or partition. Either X or 9 will
work." (from xnu building for mortals - circa 10.1.1)
I am rather speechless. This seems like a rather obsolete suggestion
for machines that ship with solely OSX now.
Is there no such way to boot from the backup kernel you made from the
primary disk?. I only have X, I don't have 9. I also only have one
Mac. Do I need to keep the original install cd's on hand whenever I am
in the mood to dabble?
I have been searching the archives for this very question... either
this is really a stupid question or everyone has enough methods to get
themselves out of binds. Can someone give me a shout out as to where I
missed the boat?
--
Mark Grimes <email@hidden>
Stateful Labs
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.