20 replies to this topic

[indigo5]

Hi All,

I love bootland! Been using it for years, and find it very useful, thanks to everyone who contributes.

I have a query, I want all the windows xp and windows 7 computers on our company network to have a recovery partition for our support staff to use.
But we cannot visit each PC....we can discuss that later.

Question 1) Firstly i would like to know can winpe or Linux based boot discs be booted from HDD, for example as a dual boot?
Querstion 2) If so when they are booted will it be entirely loaded into memory or will it be running from the HDD after its loaded initially?

If someone can help with those questions it would be very useful, we can then move onto the next thing should be pretty simple.

Thanks everyone!

Indigo.

[Sha0]

I have a query, I want all the windows xp and windows 7 computers on our company network to have a recovery partition for our support staff to use.
But we cannot visit each PC....we can discuss that later.

Question 1) Firstly i would like to know can winpe or Linux based boot discs be booted from HDD, for example as a dual boot?

.ISOs do not, in general, expect to be booted as-is from an HDD. Why does it fail? Because when the OS goes looking for its CD/DVD, there isn't one available. Why do you wish to use a "boot disc"? Why not use a Windows PE or Linux right from the recovery partition?

Querstion 2) If so when they are booted will it be entirely loaded into memory or will it be running from the HDD after its loaded initially?

That really depends on what you install to the recovery partition.

For example, if you have a BartPE .ISO with WinVBlock in it, then you would boot the virtual disc to RAM. If you boot a Linux kernel and all the files you need are in the initramfs "initrd", then all of that would be in RAM, too. If you boot a newer Windows PE from a .WIM file, then that'd be in RAM, too. If you boot a BartPE on the recovery partition, that would run from the partition and would not have such hefty RAM requirements. If you boot Linux and that Linux uses the recovery partition, then that would not have such hefty RAM requirements.

[sbaeder]

Another way to answer the above is YES - you can make a set of recovery files that can live in a separate partition that can be booted, and YES (if you want to) you could make it live in RAM after booting (or access the disk for part or all of the files)...All depends on what you have the boot process do...

[indigo5]

This is excellent thanks guys.

So my first questions was probably wrong terminology, you've answeered it though very well.

1)So i can put winpe or linux based recovery partition as a dual boot....yes
2) and both can be entirely loaded into RAM...yes

So the next stage is to decide which recovery parition to use, it must be the same for XP and Windows 7 computers and must be able to be fully loaded into RAM with a few tools so that the HDD can be manipulated without the tools being read from the HDD.
Example: disk wipe tools, disk checking tools etc,

-Any advice on that?

-once thats decided it would be great if we could discuss how we can distribute this to multiple computers via some kind of script or i can package it into an .exe....

Thanks again,

Indigo.

[Wonko the Sane]

@Indigo
Good, now that your initial questions have been answered, it seems to me like you need some thinking about what you later posted.

First thing:

• a recovery partition is ONLY meaningful IF some basic structure on the hard disk are still operational

Since we are talking of a "dual boot", there is the need to provide a "fork" in the booting to allow to choose between the "normal" boot and the "recovery" one.

This fork can happen:

• at the MBR level
• at the PBR level
• at the bootmanager level

Simplest is at the MBR level, using a single sector MBR code that can "switch" between partitions.
There are a few such MBR's freely (besides Commercial solutions) available, most notably partita, mbldr and terabyte's mbr.
This may prove to be a non-viable solution for Windows 7's using bitlocker feature, though.

Loading/setting things at the PBR level involves anyway the use of a bootmanager (like grub4dos or Syslinux/etc.).

The "least intrusive" solution is using the default OS bootloader to chainload a bootmanager, but this has a few drawbacks for "corporate use", like the fact that every user will be presented the choice to boot from the recovery partition.

In ANY case, the idea of loading something in RAM and from it being able to WIPE the system disk drive is IMNSHO "pure folly".

If anything goes wrong, a blackout, a hardware failure that triggers the PSU shutdown protection, a software lock/error of any kind, and you can easily have a system that has NO OS NOR recovery partition anymore, thus vanifying the whole idea.

Also keep in mind that from what you write you are looking for a foolproof solution, and creating one may be a lot of work, as Douglas Adams put it :

A common mistake people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.

Consider also a "plan B", i.e. having a CD/DVD or USB device capable of "recovering the recovery partition" or however boot the machine/fix it if anything goes wrong.


Wonko

[indigo5]

Thanks Wonko,

Good advice there, Im comfortable with what im trying to achieve here, your right with everything you said, but im definitely looking to get this sorted and as soon as possible too.

its sole purpose is NOT to wipe but its an example of a tool that would need to be loaded into memory, thats why i used it as an example. I understand your point though, thanks.

So heres the solution so far right?

- use standard OS bootloader, chainload a boot manager that will start WinPE (a user prompt is fine i expected that)
- or use an MBR loader (bit locker will not be an issue, its not used)
- load the Winpe with the tools required

if we went with an mbr would i be required to have a seperate partition, if so thats not workable as the machines are already built and so doing that in retrospect would be hard without visiting each machine i think(?)

Any reccomendations on a bootmnanager that car boot to .wim or vmdk or .iso...it must boot into memory though.


This is really taking shape now, i new this was the right place to come!

[Wonko the Sane]

Well, you asked about a recovery partition, remember?

The "single sector MBR" implies having a dedicated partition.

Since you want to boot a recovery image and you want to do it from the "main" OS bootloader, you can use grub4dos allright, as it can (yes, in RAM, if you have enough - be aware that since you are looking for a "company wide" solution you have to take as target the single machine in the company with less RAM on board):

• boot *any* Linux based image
• boot a PE 2.x/3.x image
• with the addition of firadisk or WinVblock, boot a PE 1.x image (or, by itself, use a Ramdisk Server 2003 SP1 image)

Wonko

[Sha0]

...
if we went with an mbr would i be required to have a seperate partition, if so thats not workable as the machines are already built and so doing that in retrospect would be hard without visiting each machine i think(?)

Well, you asked about a recovery partition, remember?

The "single sector MBR" implies having a dedicated partition.

Well, not necessarily. If you have a partition image file, let's say WinPE.FAT, and you make it contiguous and find out which sector it starts at (relative to the beginning of the disk) you can spoof that image file as a partition in an MBR. Ghost has done this for years as one means of booting their DOS client. It seems fairly attractive as it involves the single file and a single MBR change and no user intervention. However, it is used in deployment scenarios and so is not typically initiated by a user (but could be). It also depends on having a functional (and reachable) OS at some point.

PXE-based strategies are pretty popular too, as they do no have any HDD requirement. I strongly recommend PXE-based strategies, where possible.

[Wonko the Sane]

Well, not necessarily. If you have a partition image file, let's say WinPE.FAT, and you make it contiguous and find out which sector it starts at (relative to the beginning of the disk) you can spoof that image file as a partition in an MBR.

Yep , you are right, but still it is an (necessarily contiguous) image addressed as a partition.

There is no problem in making an entry for it in the MBR, but what will happen (since we are talking of already configured and running systems) at next Defrag/File optimization?


Wonko

[sbaeder]

One other thing to consider is that if the main OS (Windows) is so hosed up it won't boot, using an MBR based approach and a separate partition will provide at least some measure of potential ability to boot...(assuming that that the partition table isn't AFU

Yes, there is the issue that if the machines are already deployed/built, but it is something to think about...

[Sha0]

Yep , you are right, but still it is an (necessarily contiguous) image addressed as a partition.

Exactly.

There is no problem in making an entry for it in the MBR, but what will happen (since we are talking of already configured and running systems) at next Defrag/File optimization?

If I recall correctly, Ghost builds the image file and modifies the MBR any time it is going to boot the image file (as a partition). Upon completion, the special partition entry is removed from the MBR. In this way, I don't think that the image file is expected to be persistent.

What the strategy might be especially good for is as a "run-once," where one could boot a utility to then resize/re-partition and then add a true utility/recovery partition.

[indigo5]

hmm thanks all, loads of options and decisions, yes if we could use PXE that would be great but its not applicable in our environment.
We dont want to change the partition size of each machine, although its one for the future perhaps.

So Wonko, you feel Grub is best then for my situation;

Grub4Dos: can it boot to .wim/iso/vmdk files?

Grub4Dos: can it be installed via script or .exe (the users are administrators but are not technical...lol!)

we need to be able to bundle the whole lot into a script/exe package which includes the grub4dos and the recovery image, they run it and they will be able to reboot and see the boot selection screen>>>?

[wimb]

Probably Make_PE3 package is useful to you.

With Make_PE3.exe you can create 7pe_x86_E.iso file (= Portable 7 PE Explorer version with Ghost) .
You can load the 7 PE ISO from Grub4dos Menu on HDD or USB and then boot from RAMDISK.
You are free then to do anything with the HDD including e.g. restore with Ghost.

You can let others use BOOT_IMG.exe to install 7pe_x86_E.iso as Grub4dos Boot option on HDD of any computer (Win7 or XP).
An improved compatible version of BOOT_IMG.exe is available in IMG_XP package.
Required files in IMG_XP folder of IMG_XP package:

\BOOT_IMG.exe

\makebt\listusbdrives\ListUsbDrives.exe

\makebt\Boot_XP\Bootfont.bin

\makebt\Boot_XP\ntldr

\makebt\Boot_XP\NTDETECT.COM

\makebt\dsfo.exe

\makebt\dsfi.exe

\makebt\grldr.mbr

\makebt\grldr

\makebt\menu.lst

Anyway it will be useful to have portable USB-harddisk with same 7PE Boot option available,
which might be used in case after booting from RAMDISK and
while restoring with Ghost an unlikely powerfailure or so would have ruined the process ...



EDIT: June 3, 2011 - BOOT_IMG_38.exe Selfextractor available as download.
This package contains the necessary files and can be used for the above given approach.
Download - IMG_XP

[Wonko the Sane]

If I recall correctly, Ghost builds the image file and modifies the MBR any time it is going to boot the image file (as a partition). Upon completion, the special partition entry is removed from the MBR. In this way, I don't think that the image file is expected to be persistent.

What the strategy might be especially good for is as a "run-once," where one could boot a utility to then resize/re-partition and then add a true utility/recovery partition.

Yep , OT , but not much , and JFYI:
http://www.wd-3.com/...e/luserland.htm
http://www.codeproje...iles/FDump.aspx
http://www.chrysocome.net/dd-backdoor

@indigo5
Be aware that you are nearing the border line between legitmate questions and otiose ones

So Wonko, you feel Grub is best then for my situation;

Do you think that I would suggest you something that won't work?

Would it be "the best"? Heck cannot say, it's "good enough" IMHO, there may be (actually there are) other solutions, you find them, try them, do a comparison, then choose the one that suits you better....

Grub4Dos: can it boot to .wim/iso/vmdk files?

As a friendly advice, when exploring options, do NOT focus on the minutiae like the actual format of the image....
The actual answer is Yes/No, meaning that it will be able to boot some of those formats BUT NOT some other ones.

You have ALREADY enough good answers to get you started, and started in the right directions , maybe it's time you start doing some of your own homework....

Of course nothing personal , but there is a limited amount of free spoon-feeding vouchers available ...

Grub4Dos: can it be installed via script or .exe (the users are administrators but are not technical...lol!)

we need to be able to bundle the whole lot into a script/exe package which includes the grub4dos and the recovery image, they run it and they will be able to reboot and see the boot selection screen>>>?

Axiom #1:

• If you can do it manually, you can also script it.

Wonko

[indigo5]

Thanks for the 'spoon feeding' everyone!

It has been really very helpful, time to build the first version.

Thanks again,

Indigo.

[Wonko the Sane]

It has been really very helpful, time to build the first version.

Keep us informed with your progresses/results.


Wonko

[indigo5]

Hi Everyone,
Im back, and instead of starting a new post I though perhaps I would revive this one as its very relevant to what im doing, the above posts slipped off the company agenda but im being asked to get on with it again now so here i am.

Heres where we are with our workstations

-Windows xp sp3
-Grub4Dos loading from boot.ini (grldr is on root of C: )
-were trying the following menu.lst file to boot an .iso into memory

title x
map --mem (hd0,0)/ERD.iso (hd32)
map --hook
chainloader (hd32)
boot

The iso were testing is ERD commander 2007 but its only to test, the test machines have 256MB RAM the iso is 145MB so I thought that would be fine...

The issue is we get a blue screen, ive ensured ERD iso works fine when booting from CD but when we chain it from Grub4Dos it blue screens the PC. It does start to boot ERD but then BSOD...!?


Any suggestions? incorrect menu.lst syntax?

Also to accomdate absolutely every pc we have we would prefer to use a variable for the HD 0,0 in the menu.lst file, is there a hex variable we can insert there? Thanks for your help all!

Edited by indigo5, 14 March 2012 - 09:27 AM.

[Wonko the Sane]

"a blue screen" means nothing.
Post the EXACT STOP ERROR CODE you get with it.

You can use find --set-root allright:

title x

find --set-root /ERD.iso

map  /ERD.iso (hd32)

map --hook

root (hd32)

chainloader (hd32)

you do not need the boot command inside a menu.lst entry (though it is needed on command line).

You do NOT want to use the --mem option on low-ram machines.
The map --mem will load the WHOLE .iso in RAM, then the "normal" ERD booting process will attempt to load the contens of the .iso in RAM, again, and this will lead to a blue screen (if this happens is to be confirmed by the STOP ERROR CODE)

The .iso will NEED to be contiguousif mapped without the --mem.

BUT the STOP ERROR you are getting is currently - most probably - a 0x0000007b, compare with:
http://reboot.pro/8827/



Wonko

[indigo5]

Thanks Wonko,
you menu.lst suggestion works great.

It still does the BSOD and yes it is the 0x0000007b error, thanks for the link.
So it would seem that weve chosen the wrong iso to test with, ERD is not the final boot disc we intend to use for this solution it was just to prove the concept, so I wil now find another boot disc .iso to use.....perhaps a linux based one...

[Wonko the Sane]

It still does the BSOD and yes it is the 0x0000007b error, thanks for the link.
So it would seem that weve chosen the wrong iso to test with, ERD is not the final boot disc we intend to use for this solution it was just to prove the concept, so I wil now find another boot disc .iso to use.....perhaps a linux based one...

You seem like having fallen in the "usual" logical error of considering "any" .iso, compare with:
http://reboot.pro/8944/
if you want to boot that ERD 2007 .iso you will need to make some changes to it's contents (as seen in the given thread - presuming that ERD 2007 has the same "base" as ERD50).
If you want to boot "something else", it may be possible without modifying it, or some other modifications may be needed, or it could be plainly "impossible" to have it boot from .iso.


Wonko

[indigo5]

Ok, thanks Wonko.

Yes i am aware that .iso files are not ALL the same.
I will choose the final set of tools that the company requires, that will then dictate which type of boot disc we will need.

Then i can come back to the challenge of getting that boot disc to work.

I am ever grateful to you!

Indigo