Jump to content

Munky's Experiments with Boot-132 - Thread Dumping Ground


munky
 Share

44 posts in this topic

Recommended Posts

so i tried booting from the pendrive and specifying 80, 81, 82........ all the way up to 9f - no luck.

 

ok im going to try this: im restoring the retail dvd onto a usb drive. i have another usb drive i will use as the install target.

 

so we're slowly getting there - boot-132 on an SD card in a usb cardreader, and the install DVD imaged onto a partition. ho hum.

 

@hagar: yeah, so it would seem. im going to proceed with the boot-132 ISO imaged onto a usb stick, and the retail DVD imaged onto a USB drive, however it will be unmodified so this is still valid. god knows why my stupid PC wont boot the CD-ROM... grrr....

 

EDIT: ahh {censored}, over 30 mins to image the DVD?? :(

Link to comment
Share on other sites

the boot-132 i had on my usb thing didnt work - it kept giving strange errors and i didnt see the [80] prompt at any point.

 

then i tried stickpin's windows method of putting boot-132 on a usb key which is mentioned, but all i get is 'boot error'.

 

really stumped at this point... ;)

Link to comment
Share on other sites

OK! Back on track...

 

I realised the reason the ISO was failing to boot was that for some reason all the files were named in UPPERCASE.

 

Used MagicISO on windows to fix up a copy of dfe's ISO with a replacement initrd.img containing the kernel as well as dsmos.kext, and the other usual suspects (SMBIOSEnabler et al).

 

booted up - about to test with the retail DVD...

 

ok we seem to be in business. i swapped the CD-R for the retail Leo disc, typed 90, then got the 'Press any key to install or press F8' message, so i hit F8 and typed:

 

rd(0,1)/mach_kernel.patched -legacy -v

 

and hit return. so far its booted up a bit but is 'Still waiting for root device'. To be honest, on this machine i've had problems with that message sitting there for a while and then booting as normal, so im going to wait a bit and see what happens.

 

progress though... :P

 

hm... ok its *still* waiting for root device. i wonder if i would have any more joy with the restored image of the DVD which i've got on a usb drive...

 

i changed my drive settings in BIOS to 'AHCI', everything was still set to legacy from before.

 

i then tried:

 

rd(0,1)/mach_kernel.patched -legacy -v -x -f -platform=X86PC

 

just for the sheer, unadulterated hell of it. no joy however, still at 'still waiting for root device'.

 

anyone got any ideas? going to try a USB dvd-rom drive, too.

 

ok just testing... think rd=diskXsY might solve this one... fingers crossed.

 

usb dvd didnt work, just got loads of EBIOS read error messages. hmm....

 

hmm.. think perhaps i need ATA drivers in my initrd.img... ah well this will have to wait for another day as i have to go collect my son :(

Link to comment
Share on other sites

IT WORKS!

 

booted the retail DVD to the language selection screen of the install routine, on a pre-Core machine ;)

 

the trick is, and dfe emailed me to tell me this - coincidentally - at the same moment the penny dropped.

 

specifying the kernel on the alternate device changes the 'root' of the system to that device. so it was waiting for root device with UUID equal to that of the RAM disk (initrd).

 

so the final set of params which let me boot to installer was:

 

rd(0,1)/mach_kernel.patched -legacy -v boot-uuid=

 

;):P :P

 

EDIT: I *really* need to go now... am going to leave it installing and do a trial boot when i get back - should be about 2 hours or so.

Link to comment
Share on other sites

IT WORKS!

 

booted the retail DVD to the language selection screen of the install routine, on a pre-Core machine :D

 

the trick is, and dfe emailed me to tell me this - coincidentally - at the same moment the penny dropped.

 

specifying the kernel on the alternate device changes the 'root' of the system to that device. so it was waiting for root device with UUID equal to that of the RAM disk (initrd).

 

so the final set of params which let me boot to installer was:

 

rd(0,1)/mach_kernel.patched -legacy -v boot-uuid=<uuid of retail leo disc>

 

:D:D:D

 

EDIT: I *really* need to go now... am going to leave it installing and do a trial boot when i get back - should be about 2 hours or so.

 

Brilliant - the boot-uuid piece should also work for the VMware work I am doing. Will try it out tomorrow.

Link to comment
Share on other sites

hecabe: on my setup, specifying rd(0,1)/mach_kernel.blah changed the system 'root', and so the boot process stalled waiting for a root device with a uuid (universally unique identifier) equal to the uuid of the initrd ramdisk, not the Leopard DVD. I override this by specifying the exact uuid I want it to boot - ie the Leo retail disc. This was the only way, on my system, that I could boot.

 

I'm intrigued that you don't suffer this problem. Perhaps its the kernel which decides to change the root device, and for some reason the one you're using has been modified to behave differently.

 

EDIT: Hecabe, did you try this on the machine in your sig? The core2duo? My machine is not able to boot the vanilla kernel, as it's a Pentium D. I wonder if that somehow makes a difference. When you boot like that, could u go to Terminal and do uname -a to make sure you are definitely using the patched kernel on ur ramdisk?

Link to comment
Share on other sites

quick update - just heading out the door but I thought I'd mention that I successfully booted the installed os - unmodified of course - on my PC. I again had to specify the uuid, this time of the hdd partition.

 

:-)

Link to comment
Share on other sites

hecabe: just to clarify (was posting earlier from iphone running out of batteries, so had to be brief :P)

 

the uuid of the root device the system is waiting for is displayed in verbose mode (-v) shortly before you start to get the 'Still waiting for root device' messages. This should match the UUID of the retail disc (if thats what you're trying to boot), or the UUID of the partition (after installation). In my tests, every time I specified a kernel on the initrd ramdisk (by using rd(0,1)/mach_kernel.whatever) the UUID it was waiting for was the UUID of the ramdisk itself (I verified this by mounting the initrd.img on my MacBook Pro and checking the 'Info' tab in Disk Utility.

 

normally, if you change the device you're loading the kernel from, the bootloader will automatically change the 'root' device for the boot to the device which contains the kernel. thus when you specify the kernel on the ramdisk, the bootstrap procedure changes the root device to the ramdisk, which is not what we want.

 

the boot-uuid=blah argument to the bootloader overrides the automatic selection of UUID with an explicit value - that is, you tell it exactly which root device to boot from, regardless of which one it thinks you should be booting from. thus it allows you to specify a kernel on the ramdisk but also specifies which device should be treated as the root device.

Link to comment
Share on other sites

Will be posible to make a autorecognition script for uuid´s and a selector for them? So will be possible to select where to boot from without manual checking the uuid´s from Leopard?

Im thinking on a scenario where is the first time you install on a machine with no os... so you dont know any uuid, nor initrd.image, nor dvd nor hd.

Thanks.

Link to comment
Share on other sites

pere: no idea but yes that would be ideal. even if the bootloader could list all available devices and their uuids...

 

Download HFSDebug, then "hfsdebug -d /dev/diskXsY -v | grep UUID"

 

I wrote a guide howto use the boot-uuid flag: http://forum.insanelymac.com/index.php?showtopic=115636

Link to comment
Share on other sites

 Share

×
×
  • Create New...