RAM Reg EWF with hibernation questions

[Guest]

After deploying system sucessfully using RAM Reg EWF with hibernation, I
still had some questions yet.
1. Now I can boot sytem with one clear hibernatefl.sys everytime, but how
can I update my EWF system, etc. adding some folds and files, install drivers
for perpherals ? If I commit these changes to HD, I can't ensure I still boot
up with the original clear hibernatefl.sys.
2. Yes, I can do some changes on protected volume by using "xpepm
-hibernate" without disable EWF. But where these changes to be stored, as I
found there's no changes occur to hibernatefl.sys file, even with the size
and date.
Thanks!

 

[Sean Liming \(eMVP\)]

Basically, you have to re-hibernate the system when you do an update. Using
the EWF APIs say like EWFCommitFile and then re-hiberate.

Regards,

Sean Liming (eMVP)
Managing Director
SJJ Embedded Micro Solutions

www.sjjmicro.com / www.seanliming.com
Author: Windows XP Embedded Advanced and Windows NT Embedded Step-by-Step

 

[KM]

You also may want to issue a reboot after EWF Commit but before the hibernate. Otherwise you will always resume to the image in
"committed state".

KM

 

[Guest]

But if you re-hibernate, it'll commit all the changes accumulated and I'm not
sure I can boot up system with the original fresh hibernate file. It againsts
the purpose of "Hibernate once/resume many". Can I commit only the pointed
change which I need, instead of all the accumulated changes?
Thanks.

 

[KM]

I realized I was not clear in my post.
Committing the EWF volume commits the hibernation file. This zeroes out the first page of the hibernation file. This will cause the
system to boot normally and not from the hibernation file on the next boot even if it is a resume.
So you need to reboot after the EWF Commit.

KM

 

[KM]

Nightman,

See my response above. Basicaly, you have to reboot after you commit the changes and after the reboot to hibernate the image again
to use HORM.

Another option for you would be using resmany.dat
(http://msdn.microsoft.com/library/e...HibernateOnceResumeManyEnvironmentWithEWF.asp). I never used or
tested it so I can't tell you how it works.

There is also a new feature of EWF on SP2 where you can commit some files (very restricted so you will unlikely use it). Read more
about it in XPe docs.

Another approach for you may be having an unprotected partition to store the files that needs to be changed often. But then please
keep in mind that you have to dismount that unprotected volume before you hibernate the image for HORM. Otherwise you can damage the
FS on that volume.

KM

 

[KM]

There is also a new feature of EWF on SP2 where you can commit some files (very restricted so you will unlikely use it). Read more

about it in XPe docs.

I was referring here to this: http://msdn.microsoft.com/library/en-us/xpehelp/html/xelrfEwfMgrCommitFile.asp

KM

 

[Guest]

Thanks KM.
Unfortunately, most of my possible changes on RAM Reg EWF system were
releated to windows system settings, etc static TCP/IP, computer name,
printers properties ... How can I commit one registry file then?

 

[Slobodan Brcin \(eMVP\)]

Hi Nightman,

You have tough questions here, but let me give you basics then we can discuss what you must do depending on what you need.

1. EWF here is not your enemy it is your friend. You can't add new files to OS partition not because of EWF but because of content
that is stored in hiberfile and that content will be used during the boot. You can't change that content so as you can see it is a
problem.
2. All config info can be placed by you on unprotected and unmounted FS on second partition.
3. Regarding hibernation file read what Konstantin and Sean have said.

In theory you could update your system without the reboot, and then just do one reboot so your system apply this changes.

This would go something like this.
1. You have deployed few clients with same HORM content on disk.
2. You of course have a master XPe.
3. You do update of XPe image as suggested by Konstantin in you lab.
4. You access this disk offline with your application that will do following.

Prepare application:
- It should log all OS partition sector differences between new master disk and disk that is used on clients. (But you can exclude
unallocated sectors by FS to save some size).
- Additionally you should mark sectors that do not belong to hibrfile. (I mean you should save hiber file changes, also you should
figure out format of hibr file so you don't save full length of it just needed content)

Update application that will be executed on clients:
- Now we need to trick EWF and make a file system updates. First you would like to read content of each FS sector that we need to
update, and then write it back. This will force RAM EWF to cache this content in memory for successive OS usage.
- With previous step we cleared path for updating FS trough disk access with new sectors. (As long as OS is not rebooted we will use
virtual data from EWF overlay instead of changed data from disk so XPe will be ignorant of change)
- It should read hibr file data from your update file and overwrite the hibrfile on disk trough disk access. (This bypass EWF and
since data is not used during the XPe work it won't crash)
- Reboot computer without committing or hibernating.

Huh, this is it sound simple ?

Regards,
Slobodan

 

[KM]

Nightman,

I have never tried that but you can give it a try.

 

[Slobodan Brcin \(eMVP\)]

Hi Konstantin,

Even if he could commit one registry file or any other file he would then have a integrity problem after resume. (We are still
talking about hibernation in this thread right?)

Regards,
Slobodan

 

[KM]

Slobodan,

No, I think Nightman has asked about just committing his particular changes but not committing the entire overlay.
At least that was my assumption

I certainly agree that this should not be used with hibernation feature unless the hiberfil.sys file is updated (either by
hibernating after a reboot, or using the procedure outlined in your other post in this thread).

 

[Sean Liming \(eMVP\)]

Interesting architectual problem as SUS, SMS, DUA come into play as well
with HORM, but re-hibernation is the only solution that I can see.


Regards,

Sean Liming
Managing Director
SJJ Embedded Micro Solutions

www.sjjmicro.com / www.seanliming.com
Author: Windows XP Embedded Advanced and Windows NT Embedded Step-by-Step

 

[Slobodan Brcin \(eMVP\)]

Sean,

What do you think about the way that I have described that would allow update without rehibernation?

Regards,
Slobodan

 

[KM]

I think HORM is not a complete embedded feature but rather just one of good use of hibernation and EWF.
Actually, there is so many interesting things that could be done in embedded space if we were having a way to change some
implementation or extend NT Loader, NT Kernel and EWF. However, none of them expose APIs (except the kernel but as we all know -
very minimum available).

Imagine ntldr extensions. Just pieces of code that ntldr calls in to (jumps to) on certain operations (before, during, after). That
could be some little programs (real/protected mode) under the root that, if found, are called from ntldr. E.g., instead of just
searching and checking resmany.dat (btw, has anybody confirmed this is working with XPe SP2?) the ntldr could load it up and jump to
a particular instruction by a specified offset. If this was well documented that could open many possibilities for extending XPe OS
features including the HORM.

The same store for EWF.sys, or some MS apps like SUS (WU Client), etc. If SUS client provided a way to call in a plug-in Dll, the
integration with EWF would be easier.

When it comes to considering XPe as a true embedded OS, it stumbles over the fact that XPe based on XP Pro binaries and XPe system
components cannot (or, better say, hard and time consuming to) be changed to meet some embedded needs.

 

[Slobodan Brcin \(eMVP\)]

Hi Konstantin,

Good suggestions, yup I agree that it would give us nice start point for making some beautiful features

Merry Christmas,
Slobodan

 

[Sean Liming \(eMVP\)]

It is interesting, and it sounds possible so long as the application being
updated doesn't go over the sectors of the older file. Or is there a method
to put extra sectors somewhere else. I not sure how you created the new
hiberfile to replace the old one. Step missing? Or did I read this wrong?

As far as empty space not used in the hiberfile, how is that recovered for
use?

Sounds like a nice low level sector app! When are you going to have it
finished

Regards,

Sean

 

[Slobodan Brcin \(eMVP\)]

Sean,

I actually did not made such application, also I'm not working on making one. I just told this as a theoretical consideration to
what can be done.

I not sure how you created the new
hiberfile to replace the old one. Step missing? Or did I read this wrong?

You should do in lab complete process of updating and rehibernating XPe. After that you create update file that you will use for
updating deployed XPe systems.

As far as empty space not used in the hiberfile, how is that recovered for
use?

I mentioned this only for case of making smaller update image file. (It will be one huge file but it does not have to be size of
full memory, this is why I mentioned this.)

It is interesting, and it sounds possible so long as the application being
updated doesn't go over the sectors of the older file. Or is there a method
to put extra sectors somewhere else.

Idea is to trick EWF to cache all sectors that we will update in RAM overlay and then we go around EWF and write update directly to
disk medium, so this way OS will be ignorant of what we are doing to it

I hope that this clear idea a bit.

Regards,
Slobodan

 

[KM]

Slobodan,

Merry Christmas!

Konstantin

Hi Konstantin,

Good suggestions, yup I agree that it would give us nice start point for making some beautiful features

Merry Christmas,
Slobodan

jump

 

[Sean Liming \(eMVP\)]

Yes. Good suggestions.

General Software has something called FirmBase that could be used to do
these low level tasks, but it doesn't match with your suggestion.

Regards,

Sean