Building LiveXP with drivers for laptop

I'm trying to build a LiveXP for my Dad's old 256MB laptop that will allow him to run a reasonable selection of software. Obviously it's not practical with 256MB to load the image into RAM and run it from there, so I'm just doing a non-WIM boot ISO to load from grub4dos. It seems I should use the BootSDI script, rather than CreateISO. However, trying to boot it in Virtualbox with the following grub4dos entry (generated by LiveXP) doesn't work and just says "Cannot mount selected partition". As I said though, I haven't got the space to load the image into RAM, so I'll need to remove the --mem anyway (or maybe it's not that simple and there's other changes I need to make to facilitate non-RAM running).

title LiveXP-Virtual-SCSI
map (hd0) (hd20) && map --hook
map --mem /I386/BOOTSDI.IMG (hd0)
map --hook
chainloader (hd0,0)/NTLDR

I understand LiveXP is a bit outdated, so I've been trying Gena but I'm not sure if that's the best either or whether I'd be better off with MultiPE? Testing in Virtualbox, my LiveXP and Win7PE ISOs boot from grub4dos mapped to (hd32) whereas the Gena one BSOD after it shows it's booting screen, but I've probably just got something set wrong in the build.

Whichever builder I use, the first thing is to get all the drivers integrated in the build. I did it a while ago, so I can't recall whether I used to script to extract them from his running XP, but I've got separate folders with the drivers for audio, CPUdriver, Ethernet, LCD_inf, modem, OpticalDriver32bit, Touchpad, USBMouse and Video.

The CPUdriver folder contains a .sys and .inf and a symbols subfolder, Ethernet .sys and .inf, LCD_inf a .icm and .inf, OpticalDriver32bit a .sys and .inf. The audio, video and Touchpad are more complex. Audio contains a number of files including a setup.exe and .cab files but also a WinXP subfolder with a ViaAudio.inf and .sys and oem.reg although I think I'd need to install the whole package somehow to get the Audio Control Panel included in the build. Video has a setup.exe and .cab files and a ATIdriver subfolder, although the files in that are compressed to e.g. atiicdxx.sy_ apart from the .cat and .inf files, The viaaudio .inf and .sys and oem.reg are in there as well, but it looks like I just copied them there by mistake! Touchpad doesn't have a setup.exe but does have some .exe files like Apoint.exe alongside the Apfiltr.inf and .sys. USBmouse has an .inf and .cab and that contains various .sys, .dll and .exe files

Maybe I'm not going about this right and there's a better way to extract the drivers from his running XP though?

Once I've got the correct driver files, do I just need to put them in Workbench/Common/drivers (in sub-folders hopefully)? What about those like the audio, modem, USBmouse and video drivers that have .exes and other files in addition to the .inf and .sys? I've tried this with my Gena build and it seems to have put the .inf and .sys files in place for all except the video driver (no doubt because they're compressed).

Ultimately I want this to boot nice and quick, which is why I want to integrate the drivers and configure PENetwork with the right settings so that the user doesn't have to watch it configuring things for too long before they can use it.

I suggest to try MedEvil's NaughtyPE. He is proud about the small size which is needed in the host.

Peter

I dont get it.
On which media is this "LiveXP" to be run?
The easiest on memory is obviously a "flat" PE (which is also much easier to tune/correct/mantain).


Wonko

I dont get it.
On which media is this "LiveXP" to be run?
The easiest on memory is obviously a "flat" PE (which is also much easier to tune/correct/mantain).


Wonko

Ah yes, should have said. It'll be running off a CF card, so I have to avoid writing to it too much.

Ah yes, should have said. It'll be running off a CF card, so I have to avoid writing to it too much.

Well, if you use a FAT filesystem (or disable last time access for NTFS) you should not have *any* write if not the ones really "necessary", remember it's a PE, it is theoretically "read-only".
And, as said, a "flat" build is the best choice in terms of maintenance.


Wonko

Well, if you use a FAT filesystem (or disable last time access for NTFS) you should not have *any* write if not the ones really "necessary", remember it's a PE, it is theoretically "read-only".
And, as said, a "flat" build is the best choice in terms of maintenance.


Wonko

Hmm, maybe I misunderstood how PE works but I kinda assumed the reason it couldn't be written to (and thus messed up) is because it's booted from an IMG which is mapped to a virtual HDD. With a "flat" build (i.e. no IMG but just the files on the CF card) what prevents it being written to and if it is somehow still read-only, how is it easier to tune/correct/maintain?

At some point I hope to get the RAM upgraded to 512MB which will make running a Win7 PE/Embedded possible as well, enabling the use of the improved Win7 RDP client, but I think perhaps it might not be possible to have both a "flat" XP PE AND a "flat" Win7PE on the CF card together, which obviously isn't a problem if they're both in IMGs.

To explain further, the main purpose of the laptop, whether running XP PE or Win7 PE will be as a thinclient to RDP to a XP or Win7 server via Wi-Fi at home, but I also want it to be able to connect to third-party Wi-Fi spots and run a browser, PDF and document readers, LibreOffice, etc when not at home.

You apparently entered the "scene" a bit too recently.

FORGET (temporarily) about whatever you read, and start again from the base.

Once upon a time, MS created this "misterious" WinPE reserved to OEM's and MSDN, etc.
Bart Lagerweji created a tool:
http://www.nu2.nu/pebuilder/
capable of creating a very similar Pre-installation Environment.
This opened a possibility to "everyone" to have his/her own PE.
Initially this environment was designed as an almost verbatim copy of a "normal" XP install CD. (at the time USB did not exist or was it it's very early stages, all you had were floppies and CD's - and a few Iomega ZIP - anyway too small to hold the needed files)
As such a PE 1.xx was (and still is) a mainly read only system that can even run from READ ONLY media.
When you place a system designed to be read only on read/write media it will still be read only at it's core, BUT it will allow you to write IF you want/need to.
If you use a mapped .iso (which is ALSO READ ONLY - just like the CD is) you will have a RO system on RO media as well, but if you use a mapped HD image you will have a RO system on RW media - just like a "flat" build is.
In a PE the Registry is "volatile" (effect of the /minnt switch), and if you want to save changes you need to "voluntarily" save them.
Of course if the media is RW it is possible that also malware/virus/whatever writes to the media, something that is "impossible" on CD (or in mounted .iso).
Using an image - be it a .iso or .img one - is all about:

• convenience (possibility of having easily several PE's without conflicts
• speed (once loaded into RAM it will work faster) and depending on several factors, like actual type of image, media hosting it, etc., etc. it may also be faster in loading.

With 256 Mb of RAM available you simply cannot "afford" to have anything but a very minimal PE loaded.
With a "flat" structure, 256 Mb are enough to run virtually everything (or almost the same programs you would on a normal XP machine with 256 Mb).

There is no conflict that I can think of between a PE 1.x and a PE 3.x on the same media, and - for the record - I never heard of a "flat" PE 3.x .
AFAIK, a PE 1.x can be both "flat" and "in image", PE 2.x or 3.x will anyway be using a .wim.



Wonko

AFAIK, a PE 1.x can be both "flat" and "in image", PE 2.x or 3.x will anyway be using a .wim.

Walkthrough: Flat-Boot Windows PE
http://technet.micro...y/hh825045.aspx
Applies To: Windows 8

http://technet.micro...5(v=ws.10).aspx

You can boot Windows Preinstallation Environment 2.0 (Windows PE 2.0) in either of two formats:
Flat file. With this format, Windows PE files live in a flat file directory structure (not an image)

http://technet.micro...5(v=ws.10).aspx

You can boot Windows Preinstallation Environment 2.0 (Windows PE 2.0) in either of two formats:

• Flat file. With this format, Windows PE files live in a flat file directory structure (not an image). Windows PE is booted directly from the flat file directory. If the flat file directory exists on the network, Windows PE will attempt to load and run directly over the network without first copying the files locally to the client computer. This method of booting Windows PE 2.0 is not available when booting from the network.
• RAMDISK. With this method, a virtual disk volume is created in the RAM to hold the boot image (which contains Windows PE). The boot image is downloaded while booting from the network and saved to this location. Windows PE is then run directly from that media.

Of which we will only explain to you the second one....


cdob, have you any examples/tutorials about a "flat" PE 2.x or 3.x (without a .wim involved) ?

I guess that Winodws 8 will be PE 4.x....



Wonko

You apparently entered the "scene" a bit too recently.

FORGET (temporarily) about whatever you read, and start again from the base.

Once upon a time, MS created this "misterious" WinPE reserved to OEM's and MSDN, etc.
Bart Lagerweji created a tool:
http://www.nu2.nu/pebuilder/
capable of creating a very similar Pre-installation Environment.
This opened a possibility to "everyone" to have his/her own PE.
Initially this environment was designed as an almost verbatim copy of a "normal" XP install CD. (at the time USB did not exist or was it it's very early stages, all you had were floppies and CD's - and a few Iomega ZIP - anyway too small to hold the needed files)
As such a PE 1.xx was (and still is) a mainly read only system that can even run from READ ONLY media.
When you place a system designed to be read only on read/write media it will still be read only at it's core, BUT it will allow you to write IF you want/need to.
If you use a mapped .iso (which is ALSO READ ONLY - just like the CD is) you will have a RO system on RO media as well, but if you use a mapped HD image you will have a RO system on RW media - just like a "flat" build is.
In a PE the Registry is "volatile" (effect of the /minnt switch), and if you want to save changes you need to "voluntarily" save them.
Of course if the media is RW it is possible that also malware/virus/whatever writes to the media, something that is "impossible" on CD (or in mounted .iso).
Using an image - be it a .iso or .img one - is all about:

• convenience (possibility of having easily several PE's without conflicts
• speed (once loaded into RAM it will work faster) and depending on several factors, like actual type of image, media hosting it, etc., etc. it may also be faster in loading.

With 256 Mb of RAM available you simply cannot "afford" to have anything but a very minimal PE loaded.
With a "flat" structure, 256 Mb are enough to run virtually everything (or almost the same programs you would on a normal XP machine with 256 Mb).

There is no conflict that I can think of between a PE 1.x and a PE 3.x on the same media, and - for the record - I never heard of a "flat" PE 3.x .
AFAIK, a PE 1.x can be both "flat" and "in image", PE 2.x or 3.x will anyway be using a .wim.



Wonko

Ah no, I've been on the "scene" for a while but unfortunately am unable to retain the little information I've picked up for very long when not putting it into practice constantly , and have been neglecting PE lately to concentrate on Thinstation (which has it's own little annoyances!)

So it won't be hard for me to forget what I thought I knew

I was sure an .iso couldn't be written to and just assumed that was also the case with a mapped IMG, but if I've understood you correctly now you're saying that with a mapped HD IMG (RO system on RW media) any changes can still be saved manually "voluntarily" back into the IMG. So I could install a driver, save the changes, reboot to allow the driver install to complete and save again to finalise it?

I can imagine it's possible for a virus/malware to "voluntarily" save unwanted changes as well in that case, but the laptop won't be used for messing about purposes, so the chances of this are reduced (and I plan to run the browser in Sandboxie to reduce this further).

The problem with the laptop is a) the HD is knackered and it takes ages to boot and do anything much even though I've tweaked XP it still seems to fill the 256MB, when initialising at least, and then of course it uses a pagefile and I refer you back to a)

So as I could get a CF card and adapter that will be a lot faster than the existing HDD and a lot cheaper than a new HDD (and will also have the benefit of reducing the weight and power consumption of the laptop), I decided that, combined with the reduced footprint of PE compared to XP, would make it a lot more usable.

Walkthrough: Flat-Boot Windows PE
http://technet.micro...y/hh825045.aspx
Applies To: Windows 8

http://technet.micro...5(v=ws.10).aspx

Cool, thanks. That will save me asking loads more questions

any examples/tutorials about a "flat" PE 2.x or 3.x (without a .wim involved) ?

start Windows Vista from a Windows PE 2.0 image by using the flat file boot method
http://support.micro....com/kb/928570/

Install Windows 7 from a VHD file: flat files are applied to a VHD file. No RAM disk is used at boot.
http://reboot.pro/14...post__p__131133

start Windows Vista from a Windows PE 2.0 image by using the flat file boot method
http://support.micro....com/kb/928570/

Install Windows 7 from a VHD file: flat files are applied to a VHD file. No RAM disk is used at boot.
http://reboot.pro/14...post__p__131133

Thanks, I'll study that to see what my options are regarding a Win7PE and/or Embedded in a VHD (considering I've only got a 16GB CF to play with).

So as I could get a CF card and adapter that will be a lot faster than the existing HDD and a lot cheaper than a new HDD (and will also have the benefit of reducing the weight and power consumption of the laptop), I decided that, combined with the reduced footprint of PE compared to XP, would make it a lot more usable.

I quite frankly doubt that a CF+adapter will be any faster than a new HD (if you are not going to spend a fortune for the CF) though obviously it will reduce weight/power consumption.
http://en.wikipedia....ki/CompactFlash
There may be also some concerns on the durability of a CF card (if not an "industrial grade" and very costly one).

You cannot have "everything" (I mean speed and low cost and durability) AFAIK.

In your situation I would (actually I already have in a very similar one) used "real" IDE Solid State (small) devices (DOM or disk-on-module) as they are - generally speaking - cheaper than corresponding industrial grade CF cards + adapter (and the reliability of such adpters is often "doubtful"), comparison example:
http://www.2pt-inf.c...products_id=535
http://www.2pt-inf.c...products_id=187

But then again if the budget is limited, I would rather invest a few bucks in a RAM upgrade to 512 Mb and get a smallish (used) HDD.


Wonko

I didn't mean CF will be faster than a new HDD, just a lot faster than the current knackered one and a lot cheaper than a new HDD (16GB CF + adapter cost me about £15). Hopefully as it's not going to be written to much, the CF should last OK.

512MB RAM upgrade will be the next thing to look into to let Win7PE/Embedded thinclient work. I might look into a used HDD sometime, but then there's always the risk it's got problems or won't last much longer anyway.

.... just a lot faster than the current knackered one

It is possible (though VERY "unusual") that a hard disk drive is "knackered" in such a way that it still works but has become "slow" , and in these cases often it is possible to "re-condition" it (by wiping it, re-initialiizing, re-installing) as often is not the device that is "slow" but rather the "install on it"...
... in my experience disk drives can start developing bad sectors,but it is very rare that they become "slow".
Also "knackered" is not a normally used technical term :
http://reboot.pro/13601/page__st__125


Wonko

OK. LiveXP creates the following files/folders in the Target folder

I386
Program Files
BOOTFLAG
bootsect.bin
ModelRam.exe

So I presume for a "flat" boot I just need to copy these to my HDD/CF card but how do I boot it with grub4dos? I tried chainloader /bootsect.bin but that just gives "cannot mount selected partition" (this is in Virtualbox on a Virtual HDD)

It is possible (though VERY "unusual") that a hard disk drive is "knackered" in such a way that it still works but has become "slow" , and in these cases often it is possible to "re-condition" it (by wiping it, re-initialiizing, re-installing) as often is not the device that is "slow" but rather the "install on it"...
... in my experience disk drives can start developing bad sectors,but it is very rare that they become "slow".
Also "knackered" is not a normally used technical term :
http://reboot.pro/13601/page__st__125


Wonko

Well I did a HDTune scan on it and it was showing (if I recall) something stupid like 6MB/s (might have been higher in places and dropping to that, but it was bad nonetheless).

"knackered" sums it fairly well I think

So I presume for a "flat" boot I just need to copy these to my HDD/CF card but how do I boot it with grub4dos? I tried chainloader /bootsect.bin but that just gives "cannot mount selected partition" (this is in Virtualbox on a Virtual HDD)

OW, come on, search here an on 911CD I might understand members that are not fluent in English, but you?

Rename I386 to minint (OR read http://www.911cd.net...showtopic=17504 )

In grub4dos prompt:

find --set-root /minint/setupldr.bin

chainloader /minint/setupldr.bin

boot

What happens?


Wonko

OW, come on, search here an on 911CD I might understand members that are not fluent in English, but you?

Rename \I386\ to \minint\ (OR read http://www.911cd.net...showtopic=17504 )

In grub4dos prompt:

find --set-root /minint/setupldr.bin

chainloader /minint/setupldr.bin

boot

What happens?


Wonko

It just reboots after grub4dos (very) briefly shows "Will load NTLDR". I tried leaving it as I386 and it did the same thing. I also tried with my Gena build (uses I386 and GenaPrograms) and that does the same thing too.

I don't really know what I'm doing, but as an experiment I put NTDETECT.COM from I386 in the root and then Gena shows "Setup is Inspecting your computer's hardware" and then stops with "txtsetup.inf is missing" so it seems even though I'm booting setupldr.bin from the folder (tried it as minint and I386) it's still looking for NTDETECT.COM and then txtsetup.inf in the root.

OK, Putting txtsetup.inf in the root as well and renaming I386 to minint makes it work

So for "fixing" any changes I make, drivers I install, do I use the Flush tool (under Apps - System Tools in Gena). Do I have to type a command line like "flush.exe -flush -fixed" or just click on the shortcut?

Once I've booted it on the laptop, what's the best way to install the drivers from the XP install on the HD into the PE? I see in Gena under Other there's Driver Import PE and Driver Import PE AE, both of which have a dropdown for "XPE - pnp multimedia script is/is NOT enabled".

How about installing all the XP updates? I imagine I'll run into problems with running out of RAM to cache these before I can run Flush to push them to the PE.

EDIT: Seems my celebrations were a bit premature. Gena boots to the desktop but then just sticks there with an empty desktop. I suspect much of the scripts are looking to I386 and so don't like that I've renamed it minint. It's I386 on the ISO anyway, so I guess there should be a way to keep it named that for a "flat" boot. The ISO isn't working at the moment either though and BSOD before even getting to the desktop.

EDIT2: Scrap that, I was just being too impatient. Gena seems to take quite a bit longer than LiveXP to finish loading the desktop!

It's I386 on the ISO anyway, so I guess there should be a way to keep it named that for a "flat" boot.

Rename I386 to minint (OR read http://www.911cd.net...showtopic=17504 )

Wonko

I did actually try editing setldr.bin to read I386 instead of minint, but that just caused it to think it was an XP install CD and started the install routine!

Anyway, as I said it's fine as minint, I was just being impatient.

I had a chance to test it on the laptop today and unfortunately it's not looking good, as it has a PCMCIA Wi-Fi card and Gena/LiveXP seem unable to access this. I tried running Driver Import and scanning the XP install and it showed a PCMCIA IDE/ATAPI Controller but it had a yellow warning next to it and gave an error when I tried to install it anyway. I found another driver for the TP-Link PCMCIA Wi-Fi card but that giave a "need bus driver" error when I tried to install it through Driver Import.

When I tried to install the ATI M1 video driver, the screen just went into a constant flicker until I rebooted. I've got an old LiveXP on there which does flicker several times after booting, but then settles down. That's using some VGA driver though. There were a couple of other unknown devices showing in Device Manager but there's a load of stuff missing completely, like the Battery driver and I have the feeling that without all the drivers installed it's running at constant full power, which obviously isn't good for a laptop. Smart Driver Backup showed a number of non-MS drivers, only some of which Driver Import showed, and a ton of MS drivers, non of which Driver Import showed.

I also tried my Win7PE (ISO but not RAM-loading) which boots OK in my 256MB Virtualbox but just BSOD during boot on the 256MB laptop. Maybe it just needs some drivers but I would have thought Win7 would have had the basics covered enough for it to boot.

I also found I was able to write to the boot drive (shown as X: with Gena) which I was surprised by as I thought one of the points of PE was that it was RO unless I flushed changes to it.

I did actually try editing setldr.bin to read I386 instead of minint, but that just caused it to think it was an XP install CD and started the install routine!

Well, I find "probable" that if a given solution has been used for years by thousands of people successfully, maybe you did it wrongly.

(lots of words) ... missing drivers .... (more words) ....driver not working ....

You cannot expect that a "generic" project will have all the needed drivers, expecially with laptops, you will need to either add the whole set of BTS drivers packs or add the specific drivers you need to the build.

I also found I was able to write to the boot drive (shown as X: with Gena) which I was surprised by as I thought one of the points of PE was that it was RO unless I flushed changes to it.

No, you got this wrong, the "System", i.e. the Registry is "volatile" and needs to be flushed, the filesystem is RW, and of course you can save files to it.
To simplify, if you run an installer on a PE, provided that the particular installer actually works (some check for a few settings in the Registry and refuse to run in a PE), you will have this effect (I give as granted that an installer does mainly TWO things: copies files to the filesystems, sets a few keys in the registry):

• files will be copied/written to the filesystem
• settings in the Registry will be written
• at next reboot any and all settings in the Registry will be NOT there anymore (while files will remain).

Wonko

Well, I find "probable" that if a given solution has been used for years by thousands of people successfully, maybe you did it wrongly.

More than probable, likely. But I'll pretend it never happened as I don't need to do it anyway.

You cannot expect that a "generic" project will have all the needed drivers, expecially with laptops, you will need to either add the whole set of BTS drivers packs or add the specific drivers you need to the build.

Indeed, but I thought Driver Import would do a better job of getting the drivers from the installed XP. The only ones it offered were those that I'd already added to the build anyway (audio, Ethernet, modem, mouse/Touchpad and video (which caused the screen to stop working anyway). I noticed I hadn't (as I thought I had) enabled the "XPE - pnp multimedia" script though, which probably explains some of the missing drivers (Battery, Machine, ACPI) though. Although maybe not, judging by the test below

Testing in Virtualbox, Driver Import gets me the missing Virtualbox Graphics Adapter, Intel AC97 Audio, Intel Busmaster IDE Controller and AMD PCNET Ethernet Adapter (the last was already installed as it was covered by the drivers I'd added to Gena) but still leaves two Unknown Devices under System Devices (which are ID'd as ROOTSYSTEM001 and ROOTSYSTEM002) and leaves the mouse and keyboard as "unknown devices" albeit without any warning symbols. This is Gena in Virtualbox (with the XPE - pnp multimedia script and after using Driver Import):



and this is XP in Virtualbox:


Maybe it will work better if I just install all the Driverpacks, I'm just wary of adding too much to the boot time and the RAM usage.

No, you got this wrong, the "System", i.e. the Registry is "volatile" and needs to be flushed, the filesystem is RW, and of course you can save files to it.
To simplify, if you run an installer on a PE, provided that the particular installer actually works (some check for a few settings in the Registry and refuse to run in a PE), you will have this effect (I give as granted that an installer does mainly TWO things: copies files to the filesystems, sets a few keys in the registry):

Ah, I get it now. Maybe I can use the EWF filter to prevent unwanted writes to the filesystem as well.

I'm wondering however if I'm not barking up the wrong tree with this little endeavour and whether a more suitable project for the laptop might be XP Embedded with the EWF as discussed
http://www.911cd.net...showtopic=14181
http://www.911cd.net...showtopic=16482

I certainly like the idea of "a STABLE XP Embedded image which runs direct from USB drive (HD, Stick) as BOOTDEVICE und looks very like XPPro (Directx9c...ALL XP Games are running) but only 200- 500MB large." and perhaps that's more likely to properly support all the laptop devices than Gena will.

I really need to put this on the backburner for now though and concentrate on building a Win7 RDP thinclient (using either Win7PE or Embedded) for an HP Vectra VL400 with 512MB. I've already got Thinstation working on it, so the rdesktop client in that covers XP RDP, but I want to get a Win7 RDP client built as well to take advantages of the improved Win7 RDP (it will only be RDP'ing to a single Win7 box).