Albuquerque

So here's what I did... 1. Create a blank folder named "Big mofo" (name it whatever you want) 2. Dump the entire contents of the firmware maintenance disc into "Big Mofo" 3. Go into the "Big Mofo" folder, into the System folder, rename the following files: initrd.img -> initrd1.img vmlinuz -> vmlinuz1 4. Dump the entire contents of the SmartStart ISO file into "Big Mofo", overwriting files when prompted. The following file changes are made to files within the Big Mofo\system folder... 5. Edit sample.msg with notepad; clear out the contents and replace it with the following: ProLiant Firmware Maintenance CD 7.40.2005_0831.65 1. Standard mode 2. Large Mem (>32gb) 3. Debug 4. Debug Bash 5. NoHT Debug ProLiant SmartStart CD 7.40.2005_0817.112 A. Standard mode B. Large Mem (>32gb) C. Debug D. Debug Bash E. NoHT Debug 6. Edit isolinux.cfg with notepad; clear out the contents and replace it with the following: check_server 1 implicit 0 allowoptions 0 prompt 1 display sample.msg label a kernel vmlinuz append initrd=initrd.img rw root=/dev/ram0 ramdisk_size=80157 init=/sos loglevel=3 ide=nodma ide=noraid pnpbios=off mem=64G label b kernel vmlinuz append initrd=initrd.img rw root=/dev/ram0 ramdisk_size=80157 init=/sos loglevel=3 ide=nodma ide=noraid mem=64G pnpbios=off label c kernel vmlinuz append initrd=initrd.img rw root=/dev/ram0 ramdisk_size=80157 init=/sos debug console=ttyS0,115200n8 console=tty0 ide=nodma ide=noraid pnpbios=off mem=64G label d kernel vmlinuz append initrd=initrd.img rw root=/dev/ram0 ramdisk_size=80157 init=/bin/bash debug console=ttyS0,115200n8 console=tty0 ide=nodma ide=noraid pnpbios=off mem=64G label e kernel vmlinuz append initrd=initrd.img rw root=/dev/ram0 ramdisk_size=80157 init=/sos debug console=ttyS0,115200n8 console=tty0 ide=nodma ide=noraid pnpbios=off mem=64G label 1 kernel vmlinuz1 append initrd=initrd1.img rw noht root=/dev/ram0 ramdisk_size=52671 init=/sos quiet=1 ide=nodma acpi=off label 2 kernel vmlinuz1 append initrd=initrd1.img rw noht root=/dev/ram0 ramdisk_size=52671 init=/sos quiet=1 ide=nodma mem=32G acpi=off label 3 kernel vmlinuz1 append initrd=initrd1.img rw noht root=/dev/ram0 ramdisk_size=52671 init=/sos debug console=ttyS0,115200n8 console=tty0 ide=nodma acpi=off label 4 kernel vmlinuz1 append initrd=initrd1.img rw noht root=/dev/ram0 ramdisk_size=52671 init=/bin/bash debug console=ttyS0,115200n8 console=tty0 ide=nodma acpi=off label 5 kernel vmlinuz1 append initrd=initrd1.img rw root=/dev/ram0 ramdisk_size=52671 init=/sos debug console=ttyS0,115200n8 console=tty0 ide=nodma acpi=off You can now create an ISO file with the contents of your "Big Mofo" folder using MKISOFS or something similar; use the ISOLINUX.BIN file (contained in the Big Mofo\system folder) as the boot sector -- no emulation, 4 sectors, offset 07c0.

Looks like my attempts at ISOLinux have been hampered by a known bug in it's kernel since the 3.05 version. I'm playing with changing the bootloader to something else to alleveiate this issue...

My company has done TONS of ghost images back and forth between PATA (standard IDE/EIDE) and SATA drives without any issue. I'm not sure why you'd have problems with the boot sector... ghost32.exe /mode=dump,src=1,dst=filename.gho followed by: ghost32.exe /mode=load,src=filename.gho,dst=1 No special switches, no messing with diskpart. Using Ghost 8.2 corporate edition from a file server share under a WinPE 2005 (Server 2003 SP1) platform.

I'm not looking for the boot sector, I want know what boot loader you used to make a multiboot disc with. I can boot Vista images all day on their own CD, but I can't yet find a bootloader that allows me to chain-load a working Vista bootsector.

What bootloader did you use?

Just thinking out loud, did you install HTA support on your PE image?

Haha! Go HP! Seems they're already way ahead of you; they're using ISOLinux on both CD's to provide an CD-based linux operating system to launch their software from. In theory, it's as simple as just adding the two CD's together and rewriting one of the ISOLinux.CFG files along with renaming of one of the INITRD.IMG files to make sure the two seperate files stay seperate. In reality, this will likely also have a few other hiccups such as equally-named _autorun directories and some other simple stuff. Also, there isn't much option for paring down the size, so it will almost certainly end up on a DVD. Is a DVD useable on your equipment? I don't recall our machines having DVD roms in them, but it's been so long since I've used the CD player on ANY of our hardware that I just don't recall. All of our servers are deployed with Altiris...

You're lucky my corporation has an OC12 and that I'm feeling generous this week I'll write back later after I have a chance to download them and peruse through the files... Edit: Go HP! Their file provider site is pretty fast; I'm pulling down at almost 1.5MB/sec... Shouldn't take long at all!

The problem would be, how many of us on this forum have access to the Compaq / HP Smartstart CD's? I have a few for an old DL380, but I don't have that server anymore. And I'm pretty sure I don't have anything for the firmware maintenance... Maybe if a few of us had access to this software, we'd have some better answers for ya.

The entire concept of a "multiboot" disc prohibits Vista being the only thing on your root though. What about prior operating systems such as WinXP, Win2003 that are still very much in production? There's gotta be a way to rig this, I'm just not quite *that* technical to find it.

From several different attempts, I am unable to get Vista 5308 to boot correctly from an external bootloader module. Hopefully someone is having better luck at this than I am

Looks like I misunderstood some of the threads I've previously read... The enhanced write filter from XP Embedded cannot be installed on any of the current WindowsPE builds. Sorry However, I know the SDI process works because I use it on my existing PE image. Look into the creation of an SDI image for your PE image (by using the XP Embeded toolkit) and it will outline how you can make your PE image smaller as well as give yourself some writeable ramdisk room for your temp files. My current image has about ~6mb of "free space" on drive X: that can be used for whatever... And yes, you have to build the entire WindowsPE to load from the SDI image. That's how you get the writeable portion; it cannot be "added on" after PE is already booted.

After a LONG involved process with this, I eventually gave up. Something breaks in the transition between loading the WIM into ram and handing that off to the underlying OS. I could push and pull in different places to make it break at varying points, but never could get anywhere with it. Besides, the Vista PE load has a LOAD of items that can be removed it seems; I'm getting functional Vista PE images that are far smaller (WIM size versus SDI size) than the WinPE 2005 image I was fighting to pare down.

Do some searching for one of two options: Either the filterdriver from XP Embedded (allows you ~32mb of ramdisk that is actually appended to any disk letter, regardless of whether it's actually writeable or not) or the SDI image method, also gleaned from XP Embedded. Both tools are essentially free, both will allow you to "write" to the X: drive just as if it were a ramdisk. The SDI method allows you to control the available space by how much "free space" you leave when you finish building the SDI image; alterantively the filter driver is always 32mb

Put the BOOTFIX.BIN file back into the CD. See your PE documentation for details.

OSCDIMG has some sort of issue with ISOLinux too... I haven't played with CDIMAGE yet (is it a seperate executable?)

Holy hell is BCDW ugly; there's no way I'm converting our BootCD to that. Big items that make me steer away is lack of compressed disk image support (current BootCD I develop contains over 50 disk images in IMZ format that would otherwise take another ~60mb of space), lack of user interface features (some of the techs need all the "menu help" they can get -- I know ) and really bad forced file structure (folders must be four-letter named, or must be in the root? WTF?) CDShell is much closer to the tool I need, but I'm not convinced yet. I think I've found another way to circumvent the ISOLinux issues by way of creating a multisession ISO. One portion will be ISO9660-1999 and the other portion will be a much relaxed ISO9660 with file versioning removed and lower case allowed. Should be feasible, working on it now.

I was really trying not to get away from ISOLinux, as I wasn't wanting to completely overhaul my CD structure. However, since I can't get BOOTMGR to load under any circumstances with ISOLinux (at least, at the moment) then I'll probably try one of your alternatives.

The most obvious thing is all the "replicated" files between all your flavors of XP and your two flavors of 2000. There are several ISO-creation packages out there that will single-store duplicate files and then use file pointers to "replicate" them to all the places they need to be. Thus, your four flavors of XP only need one physical copy of Shell32.dll and thus saving you ~24mb just for that single file. Other things you could do might include using UPX to compress various executable and DLL files -- sometimes by more than 50% each. I use UPX on my PE implementation for various files to make the overall image smaller. At worst, you could just use a DL-DVDR

What OS are you building it from? (XP, 2003) What PE OSD are you using to build it with? (2004,2005) Does it straight load from the CD or are you using the /INRAM or RAMDISK method? Have you tried building your PE image without the extra added drivers?

From google search: You also need MDAC installed on your PE image to make it work...

Generally speaking, you're completely out of luck. From Bart's intro-to-BartPE page:

Sorry to continue replying to myself, but if anyone else is reading I want to make sure you're in the same place that I am. Turns out I missed some fundamental mixture of command switches before; I'm able to get past the CDBOOT failure if I use MKISOFS with the -d -udf switches (omit trailing periods, make UDF format). Problem is, I now get NO error at all. I can only assume the bootsector worked and it did indeed start BOOTMGR, but it hangs at that point. Not sure if it's BOOTMGR hanging, or maybe BCP file isn't right, or maybe both worked but it chokes on the boot.wim (I know the WIM itself is good, but maybe something about the CD filesystem structure isn't right) And as I mentioned earlier, UDF completely breaks my PE 1.6 image. NTLDR goes missing supposedly... Maybe if I can ever get BOOTMGR working I can then use BCP and create a legacy entry for the "old" PE. Realistically the two will not need to co-exist in the long term, but while we're testing, I want to have both options available -- and on the same disc if at all possible.

Not sure if WDS would make up for the speed gain of multicasting a single sysprepped image to 100 machines simultaneously. That's two hundred gigabytes of data transfer (in simplistic terms) that must be moved one way or another, and WDS just isn't going to move it that much faster in my opinion. XIMAGE still definitely has uses, especially in an upgrade methodology. Just not sure it's going to replace Ghost anytime soon for massive deployment of brand new machines. (We lease refreshed over a thousand machines this quarter; there's probably 50 machines at any given time being imaged in our implementation department) Edited because I can't do math

Ok, thought I'd post a few updates. First, I can make my original version of PE 1.6 fail with an almost identical error if I remove the -N argument from MKISOFS. Hmm... So that prompted me to start monkeying with all the command switches in MKISOFS to see if I could cure it. I've tried writing the CD in UDF format and in mixed ISO9660/UDF format to no avail (but it promptly breaks previous versions of PE, so I suggest not trying). I've tried various implementations of relaxed ISO file names to seemingly no avail (37 character limit, allow lowercase, omit trailing period, allow untranslated file names). I went on to manipulate the Joliet naming standard in various ways without finding any luck there either. I'm starting to reach my technical limit on this. My only other thought is to somehow manipulate the BCD file and perhaps monkey around in there. I'm not sure where else to go...