13 replies to this topic

[amalux]

I'm looking for a way to save any changes made during a LiveXP (or nativeEx) boot 'session'. So, for example, after booting to an ISO with qEmu Manager (or qemumenu.bat) I make some configuration changes, install some app's etc. and then close the session; ALL those changes are lost, even though the OS is perfectly capable of saving my changes! There must be a way to save those changes to a new ISO so that the next time I boot this project, I'm not back to square 1. I suppose the real question is, how do you create an ISO 'backup' image of the current state OS as it exists on the virtual disk? If I can get that piece of the puzzle, the rest is easy

[was_jaclaz]

Short answer:
NO.

Long answer:
NO, the ISO filesystem is "by definition" Read Only" you CANNOT write to a ISO filesystem.
The WHOLE idea of "Live" is that NO changes can be made to the system.
What you can do is use different approaches, instead of .ISO.
Check the work of Sanbarrow and Pavel on 911CD forum with disk images and NTFS links.

jaclaz

[MedEvil]

I actually liked the idea of using fbwf on a usb stick and comitting the changes at the end.
There was a script posted for this a couple of days ago.
It was called xxxfbwf or something like that.

[was_jaclaz]

I actually liked the idea of using fbwf on a usb stick and comitting the changes at the end.
There was a script posted for this a couple of days ago.
It was called xxxfbwf or something like that.

Yep, but USB sticks and .ISO images booted in a VM are two VERY different things.

jaclaz

[MedEvil]

Yep, but USB sticks and .ISO images booted in a VM are two VERY different things.

Oh really?
I just thought, since using CDs is out of the question, i give amalux a good alternative.

You know how it is, sometimes one can't see the woods for all the trees standing in the way.

[amalux]

jaclaz Posted Today, 03:15 AM
Short answer:
NO.

Long answer:
NO, the ISO filesystem is "by definition" Read Only" you CANNOT write to a ISO filesystem.
The WHOLE idea of "Live" is that NO changes can be made to the system.
What you can do is use different approaches, instead of .ISO.
Check the work of Sanbarrow and Pavel on 911CD forum with disk images and NTFS links.

jaclaz

It's true you can't make these changes to an existing ISO but you can create a new ISO that captures the last state (good enough for me ) My question is how to create the new ISO from the hard drive before closing the session and flushing the changes. I am very familiar with the principle of creating new backup images of entire hard drives; I do it all the time with Power Quest DriveImage and Ghost (not as familiar with DriveImageXML but seems similar). So, basically, I'm just looking for a way to do this for the drive where the ISO image is mounted. My problem is a lack of understanding the differences between booting from a hard disk and booting from an ISO (or removable media) so, here's my question:

Can an existing ISO image be (temporarily) transfered to a hard drive (virtual or physical) where the changes can be made and saved, then, a new ISO created from that ?

p.s.

I'll definitely look for that work of Sanbarrow and Pavel you mentioned, just wanted to post this reply before heading out. Thanks Jaclaz

[was_jaclaz]

Again, sorry , but it is not possible.
The ISO image you boot from is, has been, was and will always be READ ONLY.
There is NO such thing as a "modified" ISO at ANY time on your system to be used as "source" for the copy.
You need to use a HD image of some kind, you must boot the VM from a Read/Write image to have the changes somewhere, otherwise ANY change is in RAM.

Though I think that theoretically it would be possible to "dump" the RAM and then, after fixing all addresses and modification made during boot, create a .ISO from it, my guess is that the procedure would be utmost complex.

But maybe there could be an alternative that could be easier to achieve is (probably):
a ".IMG to .ISO" converter, i.e. a batch or script that:
1) makes a temporary copy of the Virtual HD image
2) mounts the copy with a virtual disk driver, like IMDISK or VDK
3) renames on the copy \minint to \I386 (but this could be avoided by using a modified SETUPLDR.BIN and/or NTLDR as proposed here:
http://www.911cd.net...o...3784&st=249
and using \I386 at HD too
4) makes the needed (are there any?) changes to drive letters, paths and Registry
5) calls mkisofs and create a new .ISO from files on the modified temporary copy

As I see it, the whole obstacle in the above is that, speaking of PE systems, the OS will be loaded ANYWAY with the kernel /minint switch, so any changes in Registry will NEVER be actually written, so you also need some way to save the Registry from RAM to the (virtual) HD, see also this:
http://www.boot-land...?...ic=2824&hl=

jaclaz

[amalux]

Though I think that theoretically it would be possible to "dump" the RAM and then, after fixing all addresses and modification made during boot, create a .ISO from it, my guess is that the procedure would be utmost complex.

Gives 'user-friendly' a whole new meaning

But maybe there could be an alternative that could be easier to achieve is (probably):
a ".IMG to .ISO" converter, i.e. a batch or script that:
1) makes a temporary copy of the Virtual HD image
2) mounts the copy with a virtual disk driver, like IMDISK or VDK
3) renames on the copy \minint to \I386 (but this could be avoided by using a modified SETUPLDR.BIN and/or NTLDR as proposed here:
http://www.911cd.net...o...3784&st=249
and using \I386 at HD too
4) makes the needed (are there any?) changes to drive letters, paths and Registry
5) calls mkisofs and create a new .ISO from files on the modified temporary copy

As I see it, the whole obstacle in the above is that, speaking of PE systems, the OS will be loaded ANYWAY with the kernel /minint switch, so any changes in Registry will NEVER be actually written, so you also need some way to save the Registry from RAM to the (virtual) HD, see also this:
http://www.boot-land...?...ic=2824&hl=

jaclaz

I had already experimented with converting the .img to .iso with MagicISO (actually, just changing the extension had the same effect ) and even tried exporting the PE RAM to file for later inclusion but gave up on the process when I realized there were additional changes stored in RAM that weren't reflected in the registry. I'm not giving up on the idea of saving changes made to a 'Live CD' but, for now I'll focus on creating (or editing) scripts to include my favorite app's in the build. Thanks Jaclaz, I knew you'd be the one to set me strait on this

[MedEvil]

amalux you know that if you ever succeed with your plan of writing the changed OS back to CD, it will not be any longer computer independant. With other words, it will not run on any computer anymore.

[amalux]

amalux you know that if you ever succeed with your plan of writing the changed OS back to CD, it will not be any longer computer independant. With other words, it will not run on any computer anymore.

I didn't know that! (I'm not sure it is now )

[was_jaclaz]

I had already experimented with converting the .img to .iso with MagicISO (actually, just changing the extension had the same effect )

(bolding is mine)

Sorry to say so, but you seem to have "skipped over" several pages of your "PC operating and filesystem" manual.

Converting means changing from a certain format to another one, a .img file has a completely different structure from a .iso file, they use different filesystems, have different sectors arrangement, have different address for boot data.

I do not use Magiciso, but "logic" tells me that if it is capable of converting a RAW disk image into an .iso file and if (something that I doubt very much) the same result can be achieved by changing the extension of the file, there are only two possibilities:
1) Magiciso is definitely overpriced, and ultimately unneeded
2) the said same result is just a renamed file, that will NEVER boot, nor be readable as a .iso

Truth to be said, you never stated that you had any actual success in your conversion experiments, so I guess it's all right (though of course experimenting starting from knowledge of the theory statistically tends to give a better success rate)....

jaclaz

[amalux]

QUOTE(amalux)
I had already experimented with converting the .img to .iso with MagicISO (actually, just changing the extension had the same effect )

Sorry to say so, but you seem to have "skipped over" several pages of your "PC operating and filesystem" manual.

It's true, I do skip over most manuals I read (my eyes just glaze over ) Everything I know, I've learned from trial and error (mostly error) but that's OK, I know enough to know I don't know it all and that sometimes the answer can't be found anywhere in the manual but only in the application.

Converting means changing from a certain format to another one, a .img file has a completely different structure from a .iso file, they use different filesystems, have different sectors arrangement, have different address for boot data.

I do not use Magiciso, but "logic" tells me that if it is capable of converting a RAW disk image into an .iso file and if (something that I doubt very much) the same result can be achieved by changing the extension of the file, there are only two possibilities:
1) Magiciso is definitely overpriced, and ultimately unneeded
2) the said same result is just a renamed file, that will NEVER boot, nor be readable as a .iso

The first part you're probably right, I don't know (didn't claim to) MagicISO can convert .img to .iso and I'm sure it does more than just change the extension (didn't claim otherwise) but the fact remains that I have changed many .img files to .iso and they work just fine (try it yourself and see ) but I never implied that this method would work in every (or even most) situations; I simply don't know. I only know it worked in the cited example, a bootable Linux image (.img) that booted fine in qEmu as an .img and booted exactly the same as an .iso and could even be burned to a CD with ImgBurn the same as any other ISO. The files are a bit large to upload for 'proof' but how about a smaller file, like a photo; would you say that I can't 'convert' a jpeg to a bitmap or to a png and have it open in an image editor and be recognized as that new file type? Here's three differant file types, tell me which one is the 'real' thing:

[attachment=2794:book.jpeg] [attachment=2795:book.png] [attachment=2796:book.gif]
I know it will be easy as two of them are just misnamed file extensions and won't work

Truth to be said, you never stated that you had any actual success in your conversion experiments, so I guess it's all right (though of course experimenting starting from knowledge of the theory statistically tends to give a better success rate)....

Well, I'm claiming success now so I guess you'll just have to conclude I'm lying or maybe you just misunderstood my intention. I don't claim to be an expert or an authority on this stuff (I'll leave that to you ), I'm just experimenting and trying new things, reading and trying to learn from those, like yourself, who know far more than I ever hope to about this subject. I only report some of what I discover if I think it's interesting (hopefully to others) but I don't take myself nearly as seriously as you obviously do

[MedEvil]

I didn't know that! (I'm not sure it is now )

If it's a PE, it's designed to work on all or at least on most PC.

About the difference between converting and renaming.
If you just rename a jpeg to bmp, a program capable of opening jpeg and bmp will show you the picture fine. However a program only able to display bmp will fail.

So as long as you use a program, which can use img as well as iso files, you can get away with just renaming things to fool some checkpoints.

The reason things work like they do in Linux is, that Linux can read all sorts of file systems even if mixed like a CD with extfs.
Besides i guess your backup uses eighter 'floppy emulation' or 'HDD emulation' to become bootable.
PE uses no emulation, but runs native.

[amalux]

If it's a PE, it's designed to work on all or at least on most PC.

About the difference between converting and renaming.
If you just rename a jpeg to bmp, a program capable of opening jpeg and bmp will show you the picture fine. However a program only able to display bmp will fail.

So as long as you use a program, which can use img as well as iso files, you can get away with just renaming things to fool some checkpoints.

The reason things work like they do in Linux is, that Linux can read all sorts of file systems even if mixed like a CD with extfs.
Besides i guess your backup uses eighter 'floppy emulation' or 'HDD emulation' to become bootable.
PE uses no emulation, but runs native.

Very interesting and makes perfect sense to me It can seem strange and frustrating at times to us 'uninitiated' that certain files or images we attempt to open are 'unrecognized' or otherwise not usable but then, with a simple change of extension; voile, all seems well.