Thursday, March 25, 2010

Restoring GRUB on Dual-Boot Vista-Ubuntu (9.10) Machine

I had Ubuntu 9.10 (Karmic Koala) installed.  I reinstalled Microsoft Vista.  This knocked out the GRUB boot menu.  To restore the boot menu, I followed some Ubuntu community documentation.  The steps I used there, boiled down for my purposes, were simply to reboot from the Ubuntu CD, go into the Ubuntu partition via the Places menu, type "mount | tail -1" to make sure the Ubuntu partition was now mounted (in my case, it said something like "/dev/sda2 on /media/UBUNTU type 3" because I had named the partition using GParted), type "ls /media/UBUNTU/boot" to make sure I had the partition containing GRUB (along with memtest86+ and other files), and then run "sudo grub-install --root-directory=/media/UBUNTU /dev/sda."  That last command did not end in a number (e.g., sda2); it was simply the drive containing the boot partition.  In place of UBUNTU in my example, I would have typed the long UUID if that was what the mount command had given me.

That pretty much fixed it.  When I rebooted, I did have a GRUB menu.  But when I opted to go into Ubuntu, I got an error message:

One or more of the mounts listed in /etc/fstab cannot yet be mounted:
SWAP: waiting for UUID=[UUID number]
Press ESC to enter a recovery shell.
I pressed ESC.  I went to Applications > Accessories > Terminal and typed "sudo gedit /etc/fstab."  This opened fstab.  The lines weren't wide enough to view clearly, so I expanded the box.  Fstab contained an entry for SWAP, which (above) was the partition that didn't boot in my case.  I started another Terminal session and typed "blkid" to see what the UUIDs were.  I saw that the UUIDs and the /dev entries for SWAP didn't match.  I changed the fstab line for SWAP to match what blkid had given me, for both the UUID and the /dev location.  (I had to use the right-click option to copy from the Terminal output for blkid.)  I saved fstab and rebooted.  That seemed to fix it; the boot proceeded normally.

Monday, March 22, 2010

Survey of Income and Program Participation (SIPP): Core Questions on Disability

In an exploration of Census Bureau statistics on disabilities, I wanted to examine the questions that were asked in the most recent panel of the Survey of Income and Program Participation (SIPP).  A SIPP Data page at the website of the National Bureau of Economic Research (NBER) seemed to indicate that results from the 2008 panel were only starting to come out.  Similarly, at the Bureau's own SIPP website, a 2008 Panel SIPP Data Product Schedule indicated that, as of March 2010, Waves 1-4 of the 2008 Panel were to have been completed, but only the Wave 1 data were actually supposed to be available.

The Census Bureau indicates that the SIPP consists of core content plus topical modules.  At present, the most recent core content shown on the Bureau's Core Content webpage is that of the 2004 Panel.  That is, the 2008 questionnaire did not appear there; this seemed to be one of several Bureau webpages that seemed not to be maintained currently.  I went back to that NBER webpage, went down to the 2008 Panel listings, and saw that there was not yet a PDF file listed on the 2008 Wave 1 Core row.  I took a look into the 08w1.zip file listed next to it, but when I unzipped it I saw that it contained only a .dat file suitable for opening in a statistics program like SPSS.

I went looking for the 2008 Panel questionnaire.  On the Bureau's SIPP User Guide webpage, I found this statement:

We are currently updating the Third Edition, 2001. The revised chapters include information on the 2001 Panel, 2004 Panel and current up-to-date information on the 2008 Panel. All chapters are currently being revised.
I opened the SIPP Users' Guide, Third Edition, 2001 PDF.  It seemed to contain a lot of useful information, but not an actual copy of any questionnaires.  This was not surprising; the 2004 questionnaires, with instructions and all, had been several hundred pages long.  I found another page, described as the SIPP FTP page, and it offered several files related to the 2008 Panel -- some data files, and also some technical text files -- but no copies of the 2008 questionnaire.  I found the reason in a footnote (p. 16, n. 11) to a Census Bureau Research Report by Moore et al. (2009), "The 2008 Survey of Income and Program Participation Event History Calendar Field Test:  Study Design and Initial Results."  That footnote referred to the "automated" SIPP questionnaire.  This explained the odd format I had seen in the 2004 questionnaires:  they had apparently been attempting to replicate, on paper, the different decisions that a computer program would make, regarding which questions to ask next, based on what the respondent said.

Revising my search, I found a reference to AttA - W1 Core Items Booklet.pdf in a RegInfo.gov webpage.  RegInfo.gov, apparently maintained by the Regulatory Information Service Center, turned out to be a repository of materials currently under review by the Office of Information and Regulatory Affairs (OIRA) within the Office of Management and Budget (OMB).  In length and format, the W1 Core Items Booklet was very similar to the 2004 questionnaires that I had downloaded earlier (above).  Unfortunately, it was dated August 22, 2007, which meant that it might not have presented the final set of questions that were actually posed to the 2008 Panel.  I searched for "W1 Core Items Booklet" and found another entry at RegInfo.gov with what appeared to be the same PDF document.  On a webpage at GovPulse.us, which appeared to be a website set up by three people who wanted to make the Federal Register more searchable, I found an indication that the Census Bureau was requesting OMB review of the Wave 6 topical modules for the 2008 Panel, with this statement:  "The core SIPP and reinterview instruments were cleared under Authorization No. 0607-0944."  A search for that authorization led to a different RegInfo.gov page, bearing the appealing certification date of January 28, 2010.  This webpage indicated that the relevant Information Collection Review (ICR) pertained to something known as the SIPP 2008 Panel Survey Instruments; and when I clicked on that link, I found myself back at the original RegInfo.gov webpage.  It seemed, in short, that the W1 Core Items Booklet dated August 22, 2007 seemed to be the final 2008 Panel Core Questionnaire.

I searched that 2008 Panel Core Questionnaire for references to "disability" and its cognates.  I found a number of such references.  I found no references to "impair" or its cognates in this Core Questionnaire, however, and the references to disability tended to be using accepted terminology rather than defining it -- referring, for instance, to "disability compensation," "disability insurance," and "disability benefits."  Because the SIPP is oriented toward income and benefits that people receive, it appears that it may be possible at least to use the data from its Core Questionnaire to make estimates about the portion of its target population for which disability affects the ability to work.  Whether that would prove necessary seemed to depend on what I could learn from SIPP's disability-related topical questionnaires.

Survey of Income and Program Participation (SIPP): Topical Questions on Disability

My search for disability statistics led me to the 314-page 2008 Panel Core Questionnaire for the U.S. Census Bureau's Survey of Income and Program Participation (SIPP).  While the Core Questionnaire did have some disability-related questions, those questions tended not to ask about the nature or extent of a disability; the concern was, rather, with whether the disability interfered with (or was perhaps the source of) the respondent's income and benefits.  It seemed that disability-oriented topical questions posed to the SIPP's 2008 Panel of respondents would shed more light on the nature and extent of disabilities experienced by people in the United States.

As with the Core Questionnaires, the Census Bureau's SIPP website did not provide ready links to its Topical Module Questionnaires after 2004.  Fortunately, the 2008 Panel SIPP Data Product Schedule found on one of the pages in that website indicated that data collection for the Work Disability History module was scheduled to take place as part of Wave 2, in January through April 2009, and that the corresponding data products were expected to be released in April 2010.  Data collection for the other disability-related Topical Modules, Functional Limitations and Disability for adults and children, was scheduled to take place as part of Wave 6, in summer 2010, with data products being released in September 2011.

By pleasant coincidence, the 2008 Panel Wave 6 Topical Modules seemed to be included on the same RegInfo.gov page from which I had previously obtained the 2008 Panel Core Questionnaire, so it was easy to get the Wave 6 modules.  The link provided on that page produced an 82-page Wave 6 Topical Modules Items Booklet, in which the Functional Limitations and Disability section ran from pages 31 to 53.  A preliminary look at some of these questions confirmed that they were not at all limited to income production, as had been the case with disability-related questions in the Core Questionnaire.

The remaining step was to find the Wave 2 Topical Modules Booklet that would hopefully include the Work Disability History module.  A search led to a Federal Register entry that cited the same OMB Control Number 0607-0944 that had applied to the 2008 Panel Core Questionnaire.  A search for that number led to a different RegInfo.gov page, where I downloaded a 2008 Panel Wave 2 Topical Modules Items Booklet, in which the Work Disability Topical Module appeared on pages 1 through 5 (PDF pages 3 through 7).  As the "work disability" moniker suggests, the questions in this module appeared to be oriented toward disabilities that interfered with work.

My ultimate purpose, in this pursuit, was to become informed on defensible ways of estimating the numbers of persons with disabilities in a particular location.  The page counts (above) told me that I was likely to get a more extensive treatment of disability concepts in the Wave 6 Topical Module, and it also seemed that that module's questions would take a broader perspective on the meaning of disability.  In a subsequent post, I look more closely into that module.

Survey of Income and Program Participation (SIPP): An Introduction

The Survey of Income and Program Participation has its roots in the War on Poverty of the Johnson Administration in the late 1960s.  It was hard to find good data on welfare and income for poor people.  To meet this need, the U.S. Department of Health, Education, and Welfare (now HHS) created the Income Survey Development Program (ISDP) in 1975.  According to Citro and Scholz (2009, pp. 18-19), the transition from ISDP to the new SIPP survey proceeded in fits and starts, narrowly surviving cancellation until 1984, when the first SIPP panel of about 21,000 households finally began.

From 1985 through 1993, new panels were introduced every February, on a rotating basis.  Within each panel, households were followed through multiple four-month waves (Citro & Scholz, p. 22).  That is, the sample was divided into four groups, and all of the households in a given group were interviewed once every four months, also on a rotating basis.  After a major redesign effort beginning in 1993, panels were interviewed every four months over a four-year period, and one panel was completed before another was introduced.  After 1993, then, panels were introduced in 1996, 2001, 2004, and 2008 (pp. 23-24, 29).

SIPP seems to have been plagued, throughout its existence, by irregular and inadequate political support and funding.  In 2006, the Bush Administration proposed to cut its budget from $44 million to $9.2 million, and to focus more than half of the latter figure on the creation of a new data collection program called the Dynamics of Economic Well-being System (DEWS) (p. 28).  DEWS would rely upon administrative sources of data, rather than a survey, to update and complement decennial census data.  Congress was persuaded that SIPP was important, however, and instead cut its 2007 budget to $33 million in 2007 (p. 29).  DEWS was downscaled, and now seems to survive as the "re-engineered SIPP."

In the 2004 and 2008 panels, it was planned that households would be followed for as many as 12 waves.  These panels used 51,400 households in 2004 and 45,000 in 2008 (pp. 25, 29).  Budgetary and resource restrictions forced a significant cutback in the numbers of households and waves in later years of the 2004 panel.  The 2008 panel now seems to have sufficient funding to carry through to completion.  Data from the 2008 panel will apparently become available in 2012.  The next panel is planned for 2013, structured as a three- or four-year series of annual interviews.

In their book, Citro and Scholz provide extensive information on strengths and weaknesses of SIPP, recommendations for improving data quality and using administrative records effectively, potential innovations in data collection, and other matters.  The general sense is that these authors consider the SIPP flawed but capable of being greatly improved, and in any event irreplaceable as a practical matter.

Saturday, March 20, 2010

Ubuntu 9.10: Mounting and Dismounting Blues

I was using a couple of external USB drives with Ubuntu 9.10 (Karmic Koala).  I found the easiest way to switch them between computers was to wait until they were inactive and then yank the USB cord from one machine and plug it into another.  This had worked pretty well, but then I got this error message:

Unable to unmount DAILY
umount:  /media/DAILY mount disagrees with the fstab
This seemed to have been related to some kind of bug.  I got this after a previous error message:
Could not display "/media/DAILY".
Error:  error stating file '/media/DAILY': Input/output error
Please select another viewer and try again
DAILY was a manually created folder in /media.  I couldn't figure out how to delete it either:  it wasn't visible in "sudo nautilus" and there wasn't an option to delete it in ordinary Nautilus.  Chris Jean fixed a similar problem with this kind of command:
sudo fuser -km /media/DAILY
This seemed like a reasonable command, given some basic information about the fuser command, so I closed down everything else and tried that.  I got this response:
Cannot stat /media/DAILY:  Input/output error
I looked that up.  It didn't seem to be a very common problem.  Several of the entries that came up in that search referred to GRUB, but I wasn't sure what to make of that.  Charles A said the input/output error usually means that a drive is going bad.  Going from something else he said, I did a search for how to mount an NTFS drive by using its UUID.  Ganesh suggested "sudo fdisk -l" to see if DAILY was connected.  It did not appear to be . . . because it wasn't.  I had just pulled out its USB cable a few minutes earlier and had neglected  to plug it back in.  I did that, but now I got this:
Unable to mount DAILY
Error mounting: mount exited with exit code 1: helper failed with:
mount: according to mtab, /dev/sdf5 is already mounted on /media/DAILY
mount failed
I typed "df" and saw that DAILY was mounted at /dev/sdf5.  I clicked on DAILY in Nautilus and got the "Could not display '/media/DAILY'" error shown above.  I got an indication that this was, again, a bug.  I decided to reboot.  That fixed everything for the time being.

Later, I took a different approach.  As advised in an Ubuntu community document, I installed pmount in Synaptic.  The recommended syntax was "pmount /dev/sdb5 DRIVE," where any available location could be used in lieu of sdb5 and where DRIVE is the name of the partition.  If just the drive name is used like this, it will be mounted by default at /media/DRIVE.  But, oops, I mounted it as root, when the whole purpose of pmount was to make it possible for a non-root user to mount a drive.  So I unmounted, typed "exit" to get out of the root prompt, and tried again:  "pmount /dev/sde5 WEEKLY."  Unfortunately, it hung.  I wondered if it was because I had already mounted and disconnected (without unmounting) a device at sde5.  Maybe I needed to use the largest previously unused letter.  I killed Terminal, unplugged and replugged the USB cable on the drive, and as a user in a new Terminal session I typed "df -h" to see what was available.  I already had something mounted as sdf5, so I tried "pmount /dev/sdg5 WEEKLY."  This gave me "device /dev/sdg5 does not exist."  It took me quite a while to discover that, actually, I had not plugged the drive back in after all.  Now it mounted as "WEEKLY_" with an underscore at the end; and when I tried "umount /media/WEEKLY," I got "/media/WEEKLY is not mounted (according to mtab)."  So, OK, I pulled the USB plug, typed "sudo nautilus," went into File System/media, right-clicked, and moved WEEKLY to trash.  I replugged the USB, killed sudo-Nautilus, and at a user prompt typed "df -h" and saw that WEEKLY had reclaimed its old post at /dev/sdd5.  Now it seemed to be working OK.  Later, when I tried using pmount another time, I got some errors, like this:
Error: directory /media/[directory name] is not empty
Error:  device /dev/sdf1 does not exist
I looked at a more detailed pmount documentation page and saw that /dev/sd?? had to be a "block device in /dev."  A forum post told me that I could identify my system's block devices by typing "sudo fdisk -l."  (That's an L, not a one.)  This sobered me up on the question of what my /dev options were.  I really had only one choice as to where to mount the drive, and when I tried pmount there, I got "Error: device /dev/sde5 is already mounted to /media/[partition name]."

(Having run out of time to fiddle with this, I left this post as a draft at that point.  I believe this problem ultimately got solved by a reinstallation.  No further comments on this issue here.)

Friday, March 19, 2010

The Purpose of a Lawyer

The Purpose of a Lawyer

A lawyer is a professional.  This means that, instead of rolling the dice and playing for all or nothing, clients place their money (a lot of their money) on someone who has spent years studying and practicing this sort of thing.  Because this person will have been interested in learning about the kinds of extreme failures that could subject him/her to malpractice liability, odds are good that his/her errors will not be too dramatic.

On the other hand, unfortunately, a professional is someone who handles the same sort of case day after day, year after year.  S/he is not necessarily very interested in the details of the client’s problem.  To borrow an example from another field, imagine a psychological specialist who is currently treating a dozen patients for grief related to the deaths of their loved ones.  This specialist may understandably confuse the names and other details of these cases from time to time, or may fall asleep during sessions after a big lunch.  Some clients will find this sort of thing distressing.  The point is, the attorney will not share the client’s interest in the case, and thus will not ride herd on everything to the extent the client might prefer.

Professional training reduces the worst-scenario costs, then, by avoiding terrible outcomes, in exchange for increasing the total numbers of client irritants:  of things that clients don’t understand, of fears that fester in their dreams, of details that the attorney mishandles, and of opportunities that slip through the cracks.  Clients become frustrated because, in many cases, their attorneys do not return their calls.  Then again, the attorney invariably has an answering machine or voicemail on which clients can vent their frustration, usually at much lower cost than if the client were actually keeping the attorney on the phone.

In short, the purpose of a lawyer, down through the centuries, has been to help sincere people to transition away from impractical expectations of truth and justice, and to realize how much their involvement with the professional system of justice will actually cost – so that, in the end, they will be grateful that it did not cost more.

Legal Specialties

Lawyers go through roughly similar educational and training processes across the country.  That said, there are a number of specialized fields of legal practice, and those fields do sometimes create their own unique sorts of situations for clients.  A few examples are provided here, so as to give some sense of what the educated client should watch out for.

Divorce.  The primary purpose of divorce law is to make the parties as angry as possible, for as long as possible.  This insures that the couple will not inadvertently become reconciled, in which case their assets might be withdrawn from the jurisprudential maw before they can be properly researched and rifled; it maximizes the incentives for warring spouses to retaliate against one another by having sex with their attorneys; and it also protects attorneys from the risk that the parties will remain on speaking terms and will thus be able to compare notes and detect inconsistencies in their attorneys’ statements.  By this arrangement, the practice of divorce law serves the important social policy of encouraging people of modest means to avoid divorce law.

Criminal Law.  Criminal law is that branch of legal practice in which wealthy people pay enormous sums to prove that they are innocent.  (An obscure subpart of criminal practice deals with those less important instances in which multitudes who cannot afford criminal defense attorneys are given opportunities to pay fines and/or go to prison for relatively acceptable periods of time.)  Mainstream criminal practice thus serves as an important resource for the generation of cultural narratives about law (in e.g., books and films), through which members of the public learn that the legal system is good and that their own experiences with it are exceptions.

Bankruptcy.  Bankruptcy is a process in which, as in criminal law, clients of sufficient means must pay a substantial retainer up-front to prove that they are innocent of accusations against them.  One difference from criminal practice is that bankruptcy law allows advance planning, prior to any crimes that may be committed, and is therefore more amenable to inferior legal talent, whereas the rules of criminal law mandate that the client must first commit the wrong, in order to see what it is like, and can only then commence the task of denying it.

Constitutional Law.  This final example of a legal specialty is one of the most prestigious of all.  Constitutional lawyers strive on behalf of those fundamental principles by which a proud nation of 300 million people can remain divisively united.  As in personal injury law (which is not covered in this brief survey), constitutional law employs a lottery system where, out of millions of players, few ordinary people will find attorneys who are willing to take their cases on an affordable basis; and of those few, very few achieve ultimate fame and fortune.  Clients should take care to minimize their exposure to constitutional law, insofar as its grand scale often aggravates the sorts of delusional thinking (regarding e.g., truth, justice) noted above, provoking dangerous departures from day-to-day realities of the justice system.

Client Education

As the preceding remarks indicate, attorneys frequently bear a heavy burden of educating their clients in the esoteric principles and procedures of law.  For example, it is often not easy for an unsophisticated person to grasp just how efficient it is to resolve disputes by simply increasing costs and delays until, as it turns out, 95% of disputes can be settled without any trial at all.  That is, 95% of the number of disputes taken to court; that number itself constitutes only a fraction of the far more numerous disputes that, thanks to the rule of law, are economically resolved without any judicial involvement at all, often through inexpensively self-administered psychological internalizations.  Where extrajudicial dispute resolution entails primitively obscene and violent measures due to the presumed inability to afford any other approach, civic-minded attorneys contribute to public legal education by advising poor people, through the media, to adopt cunning strategies of retribution that are more appropriate in a civilized society.

Fortunately, the process of client education is now being assisted by modern advances in court management and by technological innovations that make law more accessible.  Thanks to the Internet, clients now have rapid, direct access to the opinions in which judges explain their application of medieval principles.  Moreover, as legal thinking continues to pervade everyday social intercourse, it is slowly eliminating logical errors attributable to common sense, so that ordinary people gradually find it more natural to reject problematic spontaneity and to rely, instead, upon the law’s rich traditions of cautious, empirically unsupported reasoning.

Conclusion

Attorney-client communications can be frustrating on both sides.  Clients frequently approach the relationship with unrealistic expectations that the attorney may feel obliged to defuse slowly, over a period of weeks or months, so that the client does not experience an epiphany that might provoke him/her to bail out abruptly.

Attorneys who try to educate clients in the law often come up against a brick wall, as clients cling to impractical forms of reasoning and vague ideas about largely irrelevant abstract principles.  Specialized areas of law add further complications.  Attorney-client communication may be best understood as a process by which attorneys dictate capsule summaries of legal culture to people of inferior cultures who can barely understand the benefits that the law provides, much less produce such benefits for themselves.

Thursday, March 18, 2010

Critique of Harris & Walton on Narrative Skills and School Conflicts

Article Reviewed:  Harris, A. R., & Walton, M. D. (2009).  “Thank you for making me write this.” Narrative skills and the management of conflict in urban schools. Urban Review, 41, 287-311.

In this article, Harris and Walton (H & W) state that Laursen, Finkelstein, and Betts (2001) “identified three types of conflict resolution strategies:  coercion, negotiation, and disengagement” in “a comprehensive meta-analysis” (p. 289).  This statement gives the impression that Laursen et al. studied categorizations of conflict resolution strategies and concluded that coercion, negotiation, and disengagement best represented the myriad taxonomies they had encountered.  That impression would be mistaken.  Laursen et al. (p. 424) did not study that question; instead, they looked to Jensen-Campbell et al. (1996) for evidence suggesting that negotiation, disengagement, and coercion might be the three strategies by which disagreements are closed.

The work done by Laursen et al. had to do, instead, with developmental trends in peer conflict resolution.  H & W observe that Laursen et al. compared the relative frequency of these three strategies at different stages of development.  H & W (p. 289) say that Laursen et al. found the following rankings at the following stages of development, with the most frequently used strategy listed first (N = negotiation, D = disengagement, C = coercion):

Childhood:  C, N, D
Adolescence:  N, D/C (equally)
Young adulthood:  N, D, C.

H & W infer, from this, that “conflict resolution strategies develop in a direction away from aggravating or aggressive strategies toward the more constructive strategies of mitigation and communication” (p. 290).  But that seems pretty glib.  One rarely finds children holding grudges for years and even decades, as adults do.  It seems that the children who try to imagine themselves in the violent settings of adults sports and wars might instead emulate adults’ admirable verbal conflict resolution skills – if the kids were seeing such skills as the standard of adulthood.

H & W devote some pages to the discussion of narratives by which children relate their conflict resolution experiences from their own perspectives.  The authors chose to focus on autobiographic narrative data because these data “show how children represent the different aspects of the conflict situation” and “can begin to reveal how children make sense of their conflicts” (p. 291).  It will soon develop, however, that some ways of making sense are privileged in these authors' eyes.

Notwithstanding the putative meta-analysis of the matter by Laursen et al., H & W divide their own discussion of these narratives into four, not three, categories:  communication and reconciliation, withdrawing from conflict, retaliation, and seeking adult help (or not).  It seems that Laursen et al. are enlisted selectively, for the purpose of supporting a scheme of linear developmental progression in the direction of negotiation and away from conflict.

So.  Having evoked the nonpresence of a tight theoretical framework, the authors proceed to marinate juicy excerpts from children's autobiographical narratives in the vinegar of their own values.  For starters, in a nation in which many adults report having no friends, and where that number is increasing, H & W aver that communication and reconciliation are the most mature conflict resolution methods.  Consider their Example 1, providing a quote from one of the children (p. 296):  “I told her how I felt when she bumped into me.  I told her that I got mad but, I knew that she [just] made a mistake.  So we both said that we were sorry.”  If only adult conflicts reaching the point of anger were routinely handled so maturely!

Oddly, the authors’ four categories do not include actual aggression or violence per se.  While I cannot lay my hands on a copy of the article by Jensen-Campbell et al. (1996) at the moment, I have the assurance of Laursen et al. that it was an empirically based piece.  Everyday experience provides its own empirical corroboration:  people do not consistently take, or even see themselves as taking, the meek route that the authors palpably prefer.  In the quote just offered, for example, the child admitted that she had been the one who had gotten mad, knowing that the other child had intended and did no harm.  The girl is commended for using “communication and reconciliation”; there is no comment on the reasonable impression that this was a conflict that she, herself, had created.

H & W provide quotes from two narratives as grist for their discussion of the communication and reconciliation strategy.  They offer a third excerpt in their discussion of the withdrawal strategy.  When they turn to the retaliation strategy, they provide their fourth quote.  “This story in Example 4,” they say, “shows much less social-cognitive and moral sophistication than did the previous examples” (p. 299).  Moral sophistication, for this purpose, appears to be measured in terms of whether the author takes “a moral stance” or assigns blame to oneself or to the other person (p. 295).  According to the authors, an instance of a “moral evaluation” occurs in Example 1 (quoted above) when the girl says, “I knew she made a mistake,” characterizing the other’s action as “an atypical lapse.”  But wouldn't it be the height of moral hypocrisy to graciously pardon the other for her mistake, when it may be one's own flash of unresonable anger that created the problem?

And so the child in the authors' Example 4 is a boy, the first such creature to appear in their examples; and his lack of moral sophistication is said to be found in his failure to offer moral evaluations, analyses of motives, or speculations as to others’ thoughts and emotions.  Apparently they think he should not have tried to describe how his little fistfight in the bathroom became a whole big to-do involving his dad and the principal and the other boy’s big brother and the Safety Council.  Had so many helpful adults become involved in the girls’ conflicts -- had their counterparts been backed up by a mean big brother -- perhaps they too would have had to devote their attention to explaining how all these people got into the mix, and why it all ultimately comes back to the fact that the other boy was hassling him.  How H & W can read his description and miss what they would otherwise consider a "moral" propensity to blame people is beyond me.

In the quoted excerpt, the boy instead takes what a lawyer might call a "strict liability" approach to the transgression at issue.  Basically, if you pick on me, you'll wish you hadn't.  It doesn't really matter what you are thinking about.  You may think you're the Queen of Sheba.  Whatever.  Just don't pick on me.  It seems, unfortunately, that H & W are not fond of a strict liability approach.  Tut-tut, they say:  there is “no evidence that the author has learned anything about how to avoid violence.”  But apparently there is no evidence that he has failed to learn anything about violence either.  Besides, why would the authors be encouraging him to “avoid” violence, when their own preferred strategy is to engage in communication and reconciliation?  The impression that both authors (Marsha and Alexis) are female does not generate confidence that they have considered the calculations by which he may have to appear strong, so as to discourage other aggressors.


The authors do go on to provide other examples that are not quite so lame.  I find their article underwhelming nontheless.  They do tell interesting stories, and their orientation toward letting the kids tell those stories themselves is commendable.  But this is one instance where conflation of conflict management and conflict suppression seems ill-advised.  The savages -- literal or figurative, in some faraway jungle or in a nearby school -- turn out to have their own cultures.  Long before the missionaries sally forth to change and fix them, we should try to understand and respect them.

Critique of Mano & Mesch on E-mail at Work

In a previous post, I critiqued a 2003 article by Friedman and Currall entitled “Conflict Escalation: Dispute Exacerbating Elements of E-mail Communication.” This post reviews a more recent article that brings out several important parts of the Friedman and Currall argument.

Article Reviewed: Mano, R. S., & Mesch, G. S. (2010). E-mail characteristics, work performance and distress. Computers in Human Behavior, 26(1), 61-69.

I found this article through a search for a present-day review of issues mentioned in my review of Friedman and Currall, whom Mano and Mesch cite. To quote the abstract, Mano and Mesch conclude (p. 61):

Using a secondary level analysis based on the Pew and American Life sample we show that extent, content, and increased volume of e-mail are (a) more frequently reported by managers than by non-managers (b) age, gender, marital status and education can become a critical issue (c) the amount of e-mail received and sent is positively related to work performance. 

Like Friedman and Currall, Mano and Mesch examined e-mail at work. Their general question for randomly dialed survey respondents (n = 394) was “the extent to which ‘.... using e-mail for work-related tasks has changed your work life’” (p. 65). Using factor analysis, they identified three major areas in which e-mail might affect respondents’ work life: work effectiveness, work distress, and work stress. In their construction, “work effectiveness” was improved if the use of e-mail increased the number of people communicated with, improved teamwork and awareness of current work events, saved time, and made the respondent more available to his/her colleagues.

“Work distress” involved the extent to which e-mail provided moments of relief, encouraged gossip, and made it too easy for people to reach the employee. “Work stress” asked whether e-mail made it impossible to get away from work, caused misunderstandings, was distracting, or added new sources of stress. Thus Mano and Mesch did not restrict their focus to the potential dispute-enlarging aspects of e-mail that had interested Friedman and Currall, but rather placed the alleged dispute-enhancing tendency into a context that took account of potential benefits of e-mail usage. Hence my critique of Friedman and Currall anticipated something similar to what I found in Mano and Mesch.

Mano and Mesch investigated four hypotheses, which boil down in general terms to the hunches that work effectiveness, stress, and distress are correlated with greater e-mail use (in terms of both time spent on e-mail and numbers of e-mails sent and received) and frequency of e-mail checking, but stress and distress are inversely correlated with the number of non-work¬related e-mails. I did not find their distinction between stress and distress to be either intuitively clear nor empirically crucial in most cases, and in this discussion thus sometimes adopt their reference to both as dimensions of “employees’ wellbeing” (p. 68) or other quality-of-life phrasings. Moreover, since they found that “e-mail with personal content neither contributes to work performance, nor is it detrimental,” and since personal e-mail was not in any event the core issue in their research, I will not focus on non-work-related e-mails. With these adjustments, their research hypotheses may be roughly phrased as the suggestion that greater e-mail use and frequency of checking is positively correlated with work effectiveness and negatively correlated with employee wellbeing. And this is essentially what they found.

The authors sought to nuance that suggestion with attention to several additional characteristics. Among such characteristics, they determined that organization size is negatively related to frequency of e-mail checking, and that numbers of e-mails are greater for managers than for non-managers. Mano and Mesch attribute the decreased well-being for employees that arises from increased e-mail usage to “information overload” (p. 68), where such overload emerges not only from the information management aspects of receiving numerous e-mails (e.g., understanding, storing, and retrieving) but also from the new tasks, priorities, and interactions required by the contents of such messages.

In addition to the limitations identified by the authors (namely, the limited number of variables available to their secondary data analysis, lack of sensitivity to occupation and task, and inability to distinguish technological and non-technological environments), I had some concerns. On a stylistic level, I was not reassured by the typographical errors and poor grammar, and I found it unhelpful that the authors would occasionally refer to undefined constructs (e.g., “better working time,” p. 66) whose meaning I could not readily ascertain. On a more substantive note, I was not impressed with the paucity of current research. On a subject as novel and evolving as e-mail (in e.g., a Facebook era), it is certainly strange for an article published in 2010 to draw upon a number of works from the 1980s (not to mention 1958), or to refer to a 2003 study as “recently published” (p. 63).

In terms of overall structure, I was not sure how the authors’ three research questions translated into their four research hypotheses, nor was it entirely clear to me that they rigorously worked through each of those hypotheses. For example, while their interest in the well-being of managers is worth noting, their concluding focus on it gave the impression that they had gotten distracted. I also found that some of their conclusory editorializing did not follow from their research. Indeed, in their remarks that “at the end of the day, work is done by people, and it is due to their individual wellbeing that work performance improves,” I thought I detected a contradiction of their apparent sense that e-mail-related well-being and performance tend to operate at cross-purposes. Nor was I persuaded that stress and distress are “undesirable” outcomes of work performance (p. 63); stress seems to be a work performance motivator in many circumstances. Most egregiously, for purposes of the present review, I was not impressed with the authors’ summary statement that unspecified “researches [sic] have shown that information conveyed via e-mail nurtures negative aspects of communication” (p. 68). I had thought that they intended, themselves, to look into e-mail as a generator of misunderstandings. I did not expect to see that notion resurrected in the conclusion if it did not emerge profoundly from their own data.

Despite such concerns, it did appear that Mano and Mesch provided a solid review of relevant literature. For purposes of learning about conflict management, this literature review (which actually began in the article’s introduction) was more informative than their own empirical research. They cite various sources for several propositions: that e-mail imposes a degree of technical neutrality insofar as very different people are compelled to communicate in a basic lingua franca, for example; that other data sets (unlike the one they used) permit differentiations among kinds of e-mails (e.g., announcements, task information); and that e-mail has the potential for multiplying positive interactions among individuals, including many who might otherwise not even become aware of one another.

Generally, it is worth considering that what e-mail opens is not Pandora’s box but is, rather, the door to the future. That is, there is a pervasive assumption that the workplace dare not become entangled in personal issues. So the personal difficulties and interpersonal conflicts of normal life become an 800-pound gorilla that everyone tries to ignore. This worked to some extent in an industrial era, especially when mental focus was not an essential ingredient in job performance. It does not work nearly as well in mentally challenging positions. It would be possible, in theory, to treat e-mail as an identifier of issues to be resolved – as, in other words, an exposer of what was previously swept under the rug. It seems that a mentally healthy workplace might coexist well with a commitment to deep, long-term integration of its participants. In that case, when Mano and Mesch observe that “e-mail has been found to generate negative outcomes as well such as ‘politicing’ and ‘petty tyranny’” (p. 62) – as if e-mail were the cause of, rather than merely an outlet for, office bullying. The analysis would be more persuasive if one were to take account of the productivity of workplaces in which there is no awkwardness-inducing device (e.g., e-mail) by which people can intentionally or inadvertently highlight barriers to growth and improvement.

Cornell's EDI 2008 Disability Status Report Webinar: A Review

Today, I watched a webinar presented by the Employment and Disability Institute (EDI) within the ILR School (formerly the School of Industrial and Labor Relations) at Cornell University.  Elsewhere, I have outlined some of the materials available on EDI's website generally.  Among those materials, it may be worth noting that EDI occasionally offers other webinars.  EDI maintains a Current News Bulletin webpage (also available in PDF and via RSS feed) that provides notifications of those webinars as well as notices of other disability-related developments; that webpage (or PDF or RSS) appears to be the best way of keeping up with such events. (The news bulletin appears to be produced by the DBTAC for the northeastern region (as distinct from the New England region), which in turn appears to be hosted by ILR.)

Today's webinar was described as "DisabilityStatistics.org Presents: The 2008 Disability Status Report."  The slides used in this webinar are presently available for PDF download.  As those slides indicate, the webinar amounted to a simple presentation of information that already seems to appear in EDI's Disability Status Reports.  It was, in other words, a video of a series of slides with voice-overs.


No doubt this presentation was exactly what some viewers needed:  it provided a summary of the printed data, in a format that some may find more accessible or interesting.  I also appreciate that, just as Cornell provides an essentially neutral home for other governmental materials, such as the United States Code, so also EDI may see its role in this regard as one of simply serving as a mouthpiece for the government.  But I was disappointed.  I hoped to hear the inside dope.  I didn’t want to just hear, without elaboration, that the 2008 ACS asked significantly different questions than previous years’ surveys, and that the resulting data are therefore not directly comparable to previous years’ results.  I already knew that; my previous post says so.  I wanted to hear why.

I wanted to hear, for example, that my own previous post was correct in its hunch that the data collection process was deliberately corrupted by the Bush Administration, in ways that no self-respecting statistician of disabilities can tolerate.  Or, alternately, I wanted to hear that, no, there were in fact very good reasons, beyond those I already surmised, for eviscerating year-to-year comparability.  I did not want to hear someone simply parrot the fact that, because of said evisceration, the loss of millions of Americans from the lists of the disabled did not mean that those people had actually ceased to have disabilities.  I wanted to hear that statisticians are taking countermeasures, in a bid to develop an approach that will give us an actual, halfway meaningful statistic on the prevalence of disabilities, and on other disability-related matters that the ACS should be covering.

Wednesday, March 17, 2010

Cornell ILR EDI 2008 Disability Status Reports

The Employment and Disability Institute (EDI) within the ILR School at Cornell University has now rolled out its Disability Status Reports on the American Community Survey (ACS) data for 2008.  These reports are available in PDF format for each state and also for the U.S. a whole.  Based on a review of a few such reports, it appears that each is a 65-page document covering the same list of topics, as presented in each report's list of contents.  (Note that the contents list items are clickable; for example, clicking on the line for "Prevalence:  All Ages" takes you immediately to page 10 of the report.)  Those topics are presented under two main headings, as follows:


Demographics
Prevalence: All Ages
Prevalence: Ages 4 and under
Prevalence: Ages 5 to 15
Prevalence: Ages 16 to 20
Prevalence: Ages 21 to 64 (Working-Age)
Prevalence: Ages 65 to 74
Prevalence: Ages 75 and Older
Prevalence: Gender and Age
Prevalence: Hispanic / Latino Origin and Age
Prevalence: Race

Outcomes
Employment
Not Working but Actively Looking for Work
Full-Time / Full-Year Employment
Annual Earnings (Full-Time / Full-Year workers)
Annual Household Income
Poverty
Supplemental Security Income (SSI)
Education: High School Diploma / Equivalent
Education: Some College / Associate's Degree
Education: Bachelor's Degree or More
Veterans Service-Connected Disability
Health Insurance Coverage
Type of Health Insurance Coverage


For example, the Employment section appears on pp. 32-33, apparently using virtually identical text and identically formatted graphs in each report, so that the first bulleted point on page 32 reads as follows in, say, the Michigan report.  I offer editorial comments on these reports in a contemporaneous post.

In 2008, the employment rate of working-age people with disabilities in MI was 33.6 percent.
whereas the Indiana report differs only by ending that first bulleted point with the words “in IN was 39.8 percent.”  In short, the reports provide a state-by-state, plain-English summary of key points that one will hopefully soon be able to obtain directly from the Census Bureau’s American FactFinder webpage for disability statistics.  (Note that EDI’s Disability Statistics webpage also links to disability data from the decennial Census and the Current Population Survey (CPS).

File Is Not Accessible. Access Is Denied.

I was using Windows XP in a VMware Workstation 7 virtual machine (VM), running on Ubuntu 9.10 (Karmic Koala).  In WinXP, I had moved some files to a new folder on a compressed external USB hard drive, and now I wanted to fiddle with the contents of that folder.  Unfortunately, I got this message:

[Filename] is not accessible.   
Access is denied.
I found a post that suggested that this might have something to do with folder sharing.  I went into VMware's VM > Settings > Options > Shared Folders.  There, I saw that the external drive was not included in the folders that were being shared.  I clicked Add, typed the name of the external drive, and went browsing for its host path.  But I couldn't add it; the dialog box was not seeing it.  It also wasn't visible in Ubuntu's Nautilus (i.e., File Browser), presumably because I had already connected to it in the VM, via VMware's VM > Removable Devices menu pick.  So now I disconnected it there, went back to Ubuntu, and waited for it to show up in Nautilus.  It didn't show up.  I went back to the VM to see what was going on, but it was definitely disconnected and was no longer visible in Windows Explorer.

Meanwhile, though, the external hard drive's light was on.  It was doing something, even though it did not seem to be recognized by any physical or virtual machines.  Some hours earlier, I had started it on a project of decompressing one of its folders.  That folder contained some large files.  So now it seemed that the drive was going to just stay locked in that process until it was done.  I left it for quite a while but, hours later, the hard drive light was still on, steady, without flickering.  I shut it down and started it back up.  Now, after a minute, Ubuntu saw it.  I went into the VM and connected to it.  When the VM saw it, I went back into VM > Settings > Options > Shared Folders and tried to add it.  But the VM still couldn't see it.  I suspected that the VM was reading from the fstab.  To explore that possibility, I disconnected from the USB drive in the VM, went back to Ubuntu, and, following some advice from one of my old posts, when Ubuntu saw the external drive again, I opened Terminal and typed "sudo blkid" and copied the UUID for the drive in question (named DAILY).  In a separate Terminal session, I typed "sudo gedit /etc/fstab" and added that UUID in two lines that looked like this:
# Entry for /dev/sde5 :
UUID=ADBG2454DBD /media/DAILY ntfs-3g defaults,locale=en_US.UTF-8 0 0
I went back into the VM and connected to the external USB drive again, and then tried again with the VM's Shared Folders option.  DAILY was still not visible there.  Maybe it was a question of what drives were visible when the VM started up?  This external drive was probably not connected and turned on at that time.  I rebooted the VM to see what would happen if DAILY was connected the whole time.  That definitely took care of the drive recognition problem, but I still got the "not accessible" error when I tried to go into the folder I was trying to view.  So I went back into the VM's Shared Folders setting and tried to add DAILY to the list of shared partitions.  Unfortunately, it was still not listed.  Ah, but back in Ubuntu, I had an error message:
Unable to mount DAILY
Error mounting:  mount exited with exit code 1: helper failed with:
mount:  only root can mount /dev/sde5 on /media/DAILY
This gave me an idea.  Did I have to be running Workstation as root in order to add DAILY as a Shared Folder in the VM?  I disconnected DAILY from the VM and went to Ubuntu to take a look at the drive permissions.  DAILY wasn't visible on Nautilus until I clicked the computer icon in the toolbar.  When I did that, it became visible on the right side of Nautilus, and that also reproduced the "Unable to mount DAILY" error message.  So it seemed that message had been generated by Ubuntu's effort to mount DAILY when I disconnected it from the VM.  But why did root have to mount DAILY?  I right-clicked on DAILY (on the right side of Nautilus) and went to Properties > Permissions.  But it said the permissions could not be determined.  So, OK, I ran "sudo nautilus" and tried that again.  But DAILY wasn't visible in Nautilus.  So I exited that and tried "sudo blkid."  DAILY was still at /dev/sde5.  nixCraft told me to make a mount point for it (in this case, "sudo mkdir /media/DAILY").  Now "sudo fdisk -l" told me that /dev/sde 5 was NTFS, in which case I could use "sudo mount -t ntfs -o nls=utf8,umask=0222 /dev/sde5 /media/DAILY" to mount it.  Now at least I was able to see that its permissions were root (not me).  Using "sudo nautilus," I went to File System > media and right-clicked on DAILY.  But I was not able to change its permissions; they changed back after I tried.  Following Merlin's advice, I went into Ubuntu's System > Administration > Users and Groups.  There, it looked like "ray" was the name of both my user and my group.  So I typed "sudo chown -R ray:ray /media/DAILY" to change the ownership of that drive (and everything on it) to ray.  This caused the external drive to grind away for maybe five minutes.  But the Permissions were still the same:  root.  Sebastian Abate made me think I might have to unmount the drive to change the permissions, and that the change of permissions would actually apply to the mount point, so I typed "sudo umount /media/DAILY."  Then I tried the "sudo chown" command again.  This time, of course, it did not make the external drive grind away.  Now I tried Sebastian's version of the "sudo mount" command:  first "sudo chmod 777 /media/DAILY" and that was the answer.  I now owned DAILY.

I went back into the VM, connected the external drive, and tried to play with it in Windows Explorer.  As I may have realized before (a day or two had passed by this point), the problem was peculiar to just one folder that I had created while the drive was owned by root.  So, OK, it seemed I needed to disconnect the drive from the VM again, go back to Ubuntu, and run "chmod -R 777 /media/DAILY."  The -R option would run the chmod command recursively, through everything on DAILY.  But that gave me "cannot access `/media/DAILY': Input/output error."  It sounded like this might have been caused by an improper shutdown, so I plugged the DAILY external drive into a WinXP computer, right-clicked on it, and did Properties > Tools > Check Now > Automatically fix file system errors > Start > Yes.  So now it would check that drive after I rebooted the Windows computer.  Meanwhile, I tried to manipulate that troublesome folder in Windows Explorer on that Windows machine, and what did I see but the same "access is denied" message!  It wasn't an Ubuntu or VM issue; it was an ntfs hard drive issue.  I rebooted and let CHKDSK do its thing.  Unfortunately, that didn't do it.  It seemed this folder was really very screwed up.  I rebooted with the Windows XP installation CD and ran CHKDSK /R from its Recovery Console.  For this 750GB hard drive, this took more than 24 hours to run twice (i.e., until CHKDSK /R reported no more errors fixed).  When it was done, I went back into that uncooperative folder.  Access was still denied.  I rebooted that dual-booting computer into Ubuntu and examined the folder there.  Ubuntu had no problems with it.  Right-clicking showed me that the folder was owned by root.  I re-ran chmod, this time specifying "sudo chmod -R 777 /media/DAILY/EXTERNAL," where "EXTERNAL" was the name of the folder in question.  This changed nothing.  I backed up another step to "sudo chown -R ray:ray /media/DAILY/EXTERNAL."  Then I re-ran chmod.  Still no change of permissions.  I tried "sudo nautilus," with Windows-style manual change of permissions but, as before, no effect.  WinXP's CHKDSK may have been good for the drive generally, but it did not seem to have changed anything regarding the recalcitrant directory.

Using Nautilus, I created a new folder, EXTERNAL2, and (in normal user mode, not root mode) I copied everything from EXTERNAL to EXTERNAL2.  Permissions were not changed.  I ran chown and chmod on EXTERNAL2.  As before, this changed nothing.  Using VMware Workstation, I went into a WinXP VM, set up DAILY as a shared folder, mapped it in Windows Explorer (Tools > Map Network Drive), and used WinEx to take another look.  Unlike in WinEx elsewhere, here I was able to view the contents of EXTERNAL and EXTERNAL2.  I deleted the contents of EXTERNAL2 in WinEx and copied them again from EXTERNAL.  Again, that in itself did not change permissions, nor did the same chown and chmod commands make any difference.  In Nautilus, I deleted EXTERNAL and renamed EXTERNAL2 to be EXTERNAL.  To delete EXTERNAL, I had to manually delete some files with names like .fuse_hidden0000ef520000009d.  In some cases, though, those files seemed to be recreated after deletion.  I found that I could delete them, one folder at a time, using the right-click Delete rather than hitting the Delete key, followed by F5.  So I did wind up with EXTERNAL2 renamed, in WinEx, to be EXTERNAL.  I bailed out of Ubuntu and rebooted into WinXP.  I noticed that, while the letters of EXTERNAL had previously been colored blue (indicating that it was a compressed folder, where it seemed that the problem may have arisen from an interruption of the compression process), this newly remade EXTERNAL folder was black (indicating no compression).  I was now able to go into EXTERNAL, see its contents, and rearrange its files and folders. I still did not know how to change its permissions in Ubuntu, but apparently that was not going to prevent me from working with it in Windows.

Summary

I think what fixed the drive was to view it in Ubuntu's Nautilus, make a copy of it, and then delete the original. I did not figure out how to change its permissions, but I was nonetheless now able to use it in Windows XP.

Monday, March 15, 2010

Backpack for Running

Contents moved to my running blog and updated.

Saturday, March 13, 2010

Using a Bootable USB Drive to Install Windows XP on an Uncooperative Laptop

As described in another post, I was trying to install WinXP on a Compaq Presario CQ60-420US laptop that would not boot from a Windows XP installation CD.  This post describes the steps I took to try to install from a USB flash drive instead.

I looked for guides on how to create a bootable USB drive using WinXP SP3.  One webpage suggested that I could use UBCD for Windows (UBCD4Win).  I had already installed UBCD4Win on the computer I was using for this investigation, so I thought this approach might make the process faster.  Following the steps on that webpage, I created a supposedly bootable USB drive, using a cheap 2GB USB thumb drive I had gotten from somewhere.  (It sounded like I had better use at least a 1GB drive.)  The webpage said it could take as long as a half-hour on a really cheap (i.e., slow) USB drive.  I plugged this USB drive into the laptop and pressed Esc during the initial boot screen to open the Startup Menu, and then F9 to bring up Boot Device Options.  It gave me only two options:  the DVD drive and the hard drive.  I exited out of that, and the system tried to Start Windows Normally and then crashed and rebooted.  I powered down, powered up, and tried again.  Same thing.  No joy.  It wasn't working.

I started over, this time creating the bootable USB drive using an OCZ Diesel 4GB USB flash drive (using FAT32 rather than FAT16 as instructed).  It still wasn't a terribly fast process.  When I stuck this one in the laptop and rebooted it and hit Esc and then F9, like before, I got a very different Boot Option Menu.  This time, we had two new entries:  DIESEL and LEGACY PCI DEVICE.  I tried DIESEL.  The screen was completely black except for a white cursor that just sat there and blinked.  (Later, I realized that it would always take a while, and that I should just be patient.  I'm not sure whether that would have solved the problem here.)

I let it go for a few minutes and then restarted the machine and tried the Legacy PCI Device option.  This seemed to be designed for booting via a network connection, from a source at the other end of an ethernet cable.  I didn't have any idea of how to do that.  It appeared that the bootable USB drive process had gone correctly, but that whatever was preventing the system from booting from the WinXP CD was also preventing it from booting from the USB.  To test that, I put the Diesel drive in another computer, which I'll call the "test" computer, and set its BIOS to boot first from the USB-FDD option, second from the USB-ZIP option, and third from the USB-CDROM option.  This gave me "Remove disks or other media.  Press any key to restart."  I did that.  On reboot, it went into GRUB.  (I had this machine set for dual-booting into Ubuntu Linux.)  I went back into the BIOS and changed the first entry to be USB-HDD.  This was my last remaining USB option.  I plugged the Diesel back in.  Once again, "Remove disks or other media."  The Diesel USB drive had given me somewhat more clarity, but it was still not working.  I had tried creating a bootable USB drive once before.  I think that one was for Ubuntu, but it had used the same BartPE components that went into this one.  It hadn't worked either -- not only for me, as I recall, but for a number of other people.

I decided to try another way of making a bootable USB drive, not involving USBCD4Win.  This time, the webpage I followed began with installing BartPE to a folder with a name like C:\pebuilder.  I had already done that, in the process of setting up UBCD4Win.  Next, they had me download and install UltraISO Premium (free to try).  It didn't look like my other CD burning programs gave me the USB-HDD burning option that they recommended, so I went ahead with the installation.  I didn't bother closing my other programs before installing.  Then I ran it as they suggested.  The result was not encouraging.  When I clicked on the drive in Windows Explorer, I got an indication that the drive was not formatted.  I took it out and put it into the test computer anyway.  When I rebooted, to my surprise I got, "Start booting from USB device."  I hadn't yet copied the I386 folder to the USB drive -- couldn't, because the source computer wasn't recognizing it -- but now I yanked it out of the target (I had hit the Pause key at that point in the target machine, so it was just sitting there, politely waiting its turn) and shoved it back into the source machine, which now recognized the jump drive as drive I: (BartPE).  I copied the I386 folder.  While that was underway, I did a quick search for the option of installing XP from the I386 folder on drive C, which I had kind of forgotten about.  It looked like a hassle, so I didn't bother with it at this point.  The I386 copy process got interrupted by an irritating Windows message that one of the files in the I386 folder was being used, so I tried again, copying this time from the I386 folder on the slipstreamed WinXP SP3 CD.

When the I386 folder was all copied to the USB drive, I jerked it out of the source machine and rammed it back into the same USB port in the test machine.  I hit a key to un-pause that machine's boot process, but got "Disk Error -- Press any key to restart."  I did that.  Now BartPE loaded.  It flashed a Windows XP opening screen, so I knew WinXP was there somewhere.  Next, BartPE gave me a screen for DiskInternals.  I killed that.  It wanted to know if I wanted to start network support.  I said no.  I didn't see the DiskPart program described in the webpage, and actually I would have rather used GParted for that anyway.  I tried DiskInternals Partition Recovery, which seemed to be the closest thing to a partitioner, but it didn't look right.  I inserted the GParted CD and went to BartPE's Go > Shut down > Restart option.  On reboot, I went back into the BIOS setup and set the CD-ROM drive to boot before the USB-HDD.

Then I decided I didn't need to be fooling with the test machine anymore.  This USB drive appeared to be working.  So I put the GParted CD into the laptop instead, and also changed its BIOS boot order as just described.  I used GParted to set up a 25GB NTFS partition and then rebooted with the USB drive.  It booted!  This time around, I skipped the partitioning and formatting step described on that webpage, and instead went to BartPE's Go > Command Prompt.  This put me at an X:\minint\System32 prompt.  I guessed this meant that X was the drive letter assigned to the USB drive.  So I did a "CD \I386" and, sure enough, there it was.  So I ran the command they indicated:
X:\i386\winnt32.exe /syspart:C: /tempdrive:C: /makelocalsource /noreboot
Woo hoo -- a WinXP installation screen!  But then, dammit, an error:
Setup cannot continue because upgrade functionality is disabled and your copy of Windows XP only allows upgrades.
Now what?  I had never gotten this before.  There was, as far as I knew, no problem with the CD itself.  A search suggested no obvious solutions.  I suspected this might be a problem caused by the use of a slipstreamed CD with the BartPE process.  I decided to try again with the second approach, to see if that cheap 2GB USB drive could also be made bootable, but using an original Windows XP SP2 CD in that process.  While that was doing its thing, I took another look at that option of installing WinXP from the I386 folder.  I found a webpage that suggested using winnt.exe instead of winnt32.exe.  Unfortunately, I was not sure how to replace the other options in the foregoing winnt32 command.  (Later, I saw somewhere that the command to use would have been X:\i386\winnt /s:X:\i386, where the /S switch defines the location of the startup files).

By this time, BartPE had finished being reinstalled on the cheap 2GB USB drive.  I checked and noticed that the installed files (including /I386) filled 934MB.  The I386 files filled about 2/3 of that by themselves.  I rebooted the laptop with the cheap 2GB drive plugged in, and it worked.  Conclusion:  the UBCD4Win process did not work, at least not unless I wanted to reinstall UBCD4Win, in case it had become screwed up during my previous use of it.  But then, spoke too soon:  the cheap 2GB drive produced the same BSOD I had gotten when trying to install WinXP from the CD.  Why would the same BartPE process work with SP3 and not SP2?  I replaced the SP2 files on the cheap USB with SP3 files (using Beyond Compare to avoid having to recopy everything) and tried again with the cheap USB.  While this was underway, I also tried booting from the SP3 CD again, as I had done at the start of this post.  Nope:  still a BSOD.  When the cheap USB had the SP3 files, I tried booting it.  Nope:  still a BSOD.  So apparently there was some difference between the Diesel USB and the cheap USB.  I tried the Diesel USB once again, just to be sure.  Sure enough; once again it loaded BartPE.

Next, I downloaded WinSetupFromUSB.  It didn’t seem to have a homepage of its own; that link was the first in a long thread about it, and there was a download link there.  It came in a .7z form, and for some reason right-clicking didn’t open up the usual Windows XP “Extract” option, so I used 7-zip to extract it.  It was a standalone; no installation process needed.  It didn’t detect anything on the cheap USB drive, but it gave me options to reformat it with either Bootice or RMPrepUSB.  But then it didn’t seem to be working, so I killed it (Ctrl-Alt-Del) and started it again.  This time it identified it as 2020MB Total (FAT) and gave me an error indicating that I should not be using FAT16 on a drive > 2GB.  So apparently those other instructions were mistaken, and maybe this was why the cheap USB hadn't worked as well as the 4GB Diesel.

I clicked on Bootice and left the Destination Disk setting at the default USB.  The Bootice tooltip had recommended using Grub for DOS, so I clicked Process MBR and chose Grub for DOS > Install / Config.  I left the default settings as they were and went with Save to Disk.  This said, “GRUB4DOS is successfully installed onto this disk!  Please copy GRLDR (and optional menu.lst) to the root of any partition of this disk.”  I clicked OK > Return > Return.  This put me back to the main Bootice dialog.  Following the tooltip, I clicked Perform Format > USB-HAD HAD (Single Partition) and chose NTFS.  I got, “The partition has been formatted successfully.  You can install some kind of MBR and PBR onto it now.”  I had already done the MBR, though, and when I clicked on that it seemed to be indicating that I would be changing the MBR, so I went on to the PBR option.  I left it at NTLDR and hit Install / Config.  This, too, seemed to have been done already.  But then, when I exited all dialogs back to the WinSetFromUSB introductory dialog, I got an error message:
Could not find primary partition on the selected disk!
Please insert USB disk with a primary partition on it and click Refresh button.
I wasn’t sure what I was doing wrong, so I clicked Refresh.  Same error again.  It went away after a few seconds, so I tried RMPrepUSB instead of Bootice.  Here, the steps were numbered.  In step 3, I changed Boot Options to XP.  I went looking for the manual and, in WinSetupFromUSB\files\tools, I found RMPrepUSB.pdf.  (There didn’t seem to be a manual there for Bootice.)  This PDF said that I would have to indicate files to be copied to the USB drive here, in step 5, if I wanted the drive to be bootable.  But what files?  I wasn’t sure, so I just went with this part.  (I noticed RMPrepUSB offered an image “File to USB” button.  From the readme PDF, it seemed this would be useful only if you already had an ISO or other image containing everything that would be needed to boot a USB drive as distinct from a CD.  I didn’t have that, so I didn’t use this.)  Then I clicked on 6, Prepare Drive.  Something went wrong at this point, probably in my choices or in another program I was running.  The system nearly froze, and I had to use Ctrl-Alt-Delete to shut down this program and another one.  I tried WinSetupFromUSB > Bootice again.  It registered the drive as formatted in FAT32, so I went to the PBR button and clicked Install / Config > OK > Return.  Next, Process MBR > Grub for DOS > Install/Configure > Save to Disk.  It said something about installing GRLDR and menu.lst to the root of any partition.  After a search and a look at several websites, I still didn’t know what or where GRLDR was, or which menu.lst to install.  Finally I found a guide on how to use WinSetupFromUSB.  This guide was unfortunately somewhat outdated.  I followed its advice in a modified sense:  I copied the entire WinXP installation CD to a new folder on drive C, and indicated that in step 5 in RMPrepUSB.  Then I clicked step 6, the Prepare Drive button, along with the other OK buttons etc. needed to get it underway.  It spent maybe a half-hour copying the contents of the WinXP installation CD to the USB drive.

When it was done, I clicked Exit and ejected the USB drive.  Before ejecting, I noticed that the contents of the drive appeared identical to those of a WinXP CD; but during the process, I had noticed a brief reference to the possibility that two partitions were being created on the jump drive, and that maybe one of them was hidden.  Maybe this would be the boot partition, and it would make it so that the jump drive really would function like a boot CD.  Maybe.  About this time, I also realized that this might have been a partly wasted effort, insofar as the cheap USB drive had not been a star performer so far; I just hadn't wanted to wipe out that hard-won Diesel drive until I thought I might have a better alternative.

At this point, I used one of the foregoing processes to make a SanDisk Cruzer 4GB flash drive bootable.  I did not record which process; it was late and I went to bed while it was underway.  A day or two passed before I got back to this project.  I booted the laptop with the SanDisk, hit Esc and then F9, and saw that I did have the SanDisk as a boot option.  It did start booting.  It went through "Starting BartPE" and showed the WinXP startup screen, but then collapsed into a BSOD.

I went back to the approach that had worked with the Diesel USB.  This time, it occurred to me, I might not need to go through the long process of copying I386 to the jump drive.  That would be necessary for a situation where a CD drive was not available; but in this situation I did have a drive that would (I hoped) read the I386 file from the WinXP installation CD.  It took only a minute or so for UltraISO to make the Diesel bootable.  When that was done, I closed UltraISO, ejected the Diesel, inserted it into the laptop, put the WinXP CD in the laptop's CD drive, booted the laptop, and did the Esc-F9 sequence on startup.  This time, unfortunately, the Diesel didn't work either; another BSOD.  I thought maybe the problem was that the machine didn't even want to see the WinXP CD, so I tried again, booting the Diesel, without the WinXP CD in the drive, but no:  BSOD again.

At this point, I abandoned this bootable USB approach.  The Diesel USB had worked the first time, to the point of giving me a command prompt.  It might work again, if I kept playing with it.  But by now I had come up with some other possible approaches, so I returned to the effort described in a separate post.

Windows XP SP3 CD Won't Boot

I was trying to install Windows XP on a Compaq Presario CQ60-420US laptop. I had just gotten it back from HP service in Texas, where they supposedly replaced the motherboard to fix a nonworking wired network interface card (NIC). They had reinstalled Vista on it, which I thought was very nice of them, and now the NIC still did not work for purposes of accessing the Internet, but did work for half of a crossover cable connection with another computer. That is, the other computer could access the laptop, but not vice versa.

So I had decided to try to see if WinXP would fare better than Vista on these problems. I wiped out the Vista partition, used GParted to create a new partition, and stuck the WinXP installation CD into the CD drive. Unfortunately, XP would not boot from the CD. GParted had just booted from the CD, so I was pretty sure it wasn’t the drive hardware per se. With the WinXP CD inserted, the computer would recognize that there was a CD in its drive, and would say, “Press any key to boot from CD,” but this just caused the thing to grind away, apparently trying to read and act upon the information on the CD, before eventually (after maybe five minutes) giving me a BSOD (blue screen of death).

I found that this problem occurred with a WinXP CD, containing slipstreamed SP3, that I had used to install XP on another computer; but it appeared somewhat different with an SP2 XP CD.   With that CD, the system went all the way through "Setup is loading files" and said, "Setup is starting Windows" before giving me the BSOD.  Then again, this may have been what was happening when the SP3 CD was grinding away; perhaps it was just not reporting all of the drivers it was loading.

To fix this, one suggestion said to disable BIOS virus detection. But the BIOS did not have a virus detection option. Someone else said laptop CDs are not eager to boot from DVDs, but this was definitely WinXP on a CD.

The BIOS Setup seemed willing to let me try to boot from a USB drive. I wondered if I could install WinXP from a 4GB USB jump drive that I had lying around. To try it, I rearranged the Boot Order so that USB Diskette on Key / USB Hard Drive came first. I wasn’t too sure how to do the rest of this process, so I started by just copying the WinXP CD directly to a 4GB USB drive. While that was underway, I researched the question and found that there were many websites on how to do this, and all of them sounded complicated.

At the same time, I continued trying to figure out what was wrong with the laptop’s DVD drive. One source said that they solved the problem by flashing the BIOS on the laptop. This seemed like a more comprehensive kind of solution, so I decided to try this second – right after inserting the USB drive with a copy of the Windows XP CD and verifying that, no, it wouldn’t install WinXP by itself; booting from that USB drive would just give me “Invalid system disk. Replace the disk, and then press any key.”

It seemed odd that the system would boot a Vista CD but would require a BIOS update in order to boot a WinXP CD.  Or at least it had booted a Vista installation CD previously.  I decided to try that again.  Sure enough, with the Vista installation CD inserted, I got “Press any key to boot from CD or DVD” and then “Windows is loading files.”  I thought about trying to slipstream Vista into a WinXP CD, but got some warnings that maybe this would not be a good idea.

So, continuing with the current plan, I went to the HP-Compaq download page and looked for a WinXP BIOS update for this laptop.  All I saw there was a firmware update named sp43474.exe, for the GSA-T50L optical drive, dated April 2009.  Firefox 3.5.8 wouldn’t download it to my other computer; I had to right-click and use the IE View extension to download successfully.  The problem now was that this update was an .exe file, which I would only be able to install from within a running Windows installation.  Catch-22!

Just to be sure, I double-clicked on the sp43474.exe file on the other computer.  It said, “This software update will upgrade the firmware of your system’s optical drive GSA-T50L to rev SC05.”  I had done a printout to PDF from a system information utility before sending the laptop to Texas, so now I searched it for a reference to this model of DVD drive.  It said that, actually, what I had (at least before sending the laptop to Texas) was an Optiarc DVD RW AD-7561S ATA Device.  This seemed to be made by Sony, whereas the GSA-T50L was made by LG.  I supposed that both might ultimately have been made by the same Chinese sweatshop somewhere, but I preferred to try to find a driver for the Optiarc.  But I was curious why my laptop would have an unofficial CD drive.  I was not able to find any references to the Sony Optiarc AD-7561S drive on the Sony Optiarc page, so apparently it was an older or in some sense unsupported model.  I stumbled across a recent thread in which someone else was tired of hassling with HP, couldn’t find a firmware update, and was at the point of just installing the wrong update to see what would happen.  Same problem in another thread.  I even found a thread on an official HP forum where they were talking about this problem.  As one participant in that last thread said, “There does not seem to be any updates for the 7561s at all.”  So, OK, updating the firmware was not an option; the more likely option was to send the machine back to HP for a replacement, assuming they were willing.  I couldn’t do that now -- I needed the laptop -- so we were back at the option of installing XP from the USB.  I went through a long effort of that nature, but ultimately abandoned it and came back to this post.

While that long effort was underway, I began looking into other possibilities.  One was to adapt an Acronis True Image backup (or you could try Macrium for freeware) of a Windows XP installation from another machine, so that it would work on this laptop's different hardware.  The Acronis option that I would need, to avoid a BSOD, seemed to be Universal Restore, which would apparently cost at least $365 (list).  Alternately, it seemed that OEMs use Sysprep to deploy the same operating system installation on many computers, but it looked like more hassle than it would be worth for just one system.  I also looked into the possibility of installing XP via network connection.  This led me to a site that specialized in boot disks.  I didn’t see how I could use any of that, unfortunately -- at least not without a substantial additional time commitment, which was impossible.

The effort to install XP from the USB did not pan out, so at this point I returned to this post.  There seemed to be two basic options.  Either find a way to develop or adapt an Acronis image from another machine so that it would work on the laptop, or get to a command prompt (via USB drive, network connection, or otherwise) and run an installation command (seemingly something like X:\i386\winnt /s:X:\i386, where the /S switch defines the location of the startup files) to install WinXP from scratch.

I wondered if (a) Windows updates were being designed and revised to defeat the Acronis approach and (b) it would be possible to bail out of a WinXP basic installation before installing many hardware drivers, and make an Acronis image at that point.  I tried that, but WinXP would crash almost immediately; and as with other efforts, it would not boot into Safe Mode either.  I figured that putting the Acronis image on the laptop would at least have installed the I386 folder there, so now maybe it was just a question of getting to a command prompt.  I didn't need BartPE on a USB stick for that; I could boot BartPE from a CD.  I had a CD version of BartPE from 2007.  I guessed it would probably work, since XP was much older than that.  But it seemed that whatever caused the laptop to crash when I had the WinXP CD inserted was also going to reject WinXP as part of a BartPE CD.

I also had an Ultimate Boot CD for Windows (UBCD4Win).  The UBCD ground away for a long time, eventually showed me the WinXP splash screen -- and didn't crash!  Instead, it gave me a choice, "Select shell to start." It still seemed to be in its process, so I waited, and it chose the automatic option for me.  It gave me an option of setting up networking, but I didn't know how to answer the question as to which sort.  I tried to cancel, but it seemed intent upon continuing, so I just used the default options.  I went to Start > Command Prompt and typed DIR C: (using capital letters here just to indicate the actual command; DOS is not case-specific) and, no, the I386 folder was actually not installed there yet.  I put the WinXP CD in the CD drive and typed DIR X: because it looked like X was the letter that UBCD had assigned to the CD drive.  I typed COPY X:\I386 C:\ and it copied files.  Then it froze.  I killed that window and tried running Start > Programs > File Management > Explorers.  None of the explorer programs would run.  Eventually I realized this was because I had removed the UBCD disc.  I put it back in and tried again.  The explorers still didn't work.  I had belatedly realized that COPY was probably not the best command, so I tried XCOPY X:\I386 C:\I386 /E /H /Y.  It copied lots of stuff, and not the way I intended.  Now all the stuff that should have been in the C:\I386 folder was instead in the root (C:\) folder.  Oops.  I wound up deleting it all and starting over.  There were just a few files in C:\ that I couldn't delete (i.e., biosinfo.inf, bootfix.bin, config.sys, and mstask.inf), and of course several folders (i.e., Documents and Settings, I386, Program Files, and Windows).  Problem:  there was no WINNT.EXE file to be found.  On my other computer, it was in C:\I386, but it was not in that folder on either the laptop or the WinXP CD.  I carried it over via jump drive.  It took UBCD a minute to recognize the jump drive, but it did.  I typed WINNT.EXE and hit Enter.  I got this:
Windows XP Setup
This program does not run on any 32-bit version of Windows.
Use WINNT32.EXE instead.
Setup cannot continue.  Press ENTER to exit.
So, OK, I jumped WINNT32*.* over to C:\I386.  (The USB flash drive was recognized as drive G, as I discovered by feeling around.  That is, I tried D: and got a partition; tried E: and got a partition; tried F: and got an error; tried G: anyway and there it was.)  But it froze.  It would copy the WINNT32.* files, but not the WINNT32*.DLL files, not even one at a time.  I tried running C:\I386\WINNT32.EXE anyway.  It gave me an error:
The file C:\I386\WINNT32U.DLL could not be loaded or is corrupt.  Setup cannot continue.
I didn't have that particular one on the jump drive, so I went back to the source machine and tried to jump it over.  But I got the same problem:  the command window froze and had to be killed.  I rebooted the computer with an Ubuntu 9.10 CD and then copied all of the WINNT32*.* files (and a WINNT32 folder) from the source computer to the laptop's C:\I386 via jump drive.  Back in UBCD, I tried running that same WINNT32 command and got that same "could not be loaded or is corrupt" error.  One post suggested this sort of message might be due to insufficient RAM.  A Microsoft webpage said that I should double-click on WINNT32.MSI.  I wasn't in a GUI, so I just tried typing WINNT32.MSI at the command line.  This opened a dialog asking me what program I wanted to use to open this kind of file.

Since I had a command prompt using UBCD, I tried a different approach.  The command I used this time was:
X:\i386\winnt32.exe /syspart:C: /tempdrive:C: /makelocalsource
But this gave me an error, stating that this command was not recognized.  I tried it again, inserting a BartPE jump drive and replacing X: with H: since H was where the jump drive was.  This worked, but it just gave me the same error message I had gotten a long time earlier:
Setup cannot continue because upgrade functionality is disabled and your copy of Windows XP only allows upgrades.
I tried replacing H with C, since I had already copied I386 to C.  This just gave me the message about WINNT32U.DLL being unloadable or corrupt.  One post led me to think that this problem might be unique to my WinXP SP3 disc, so I loaded an SP2 disc and tried winnt32.exe with that.  That did not seem to achieve anything:  the disc spun up and then down and I was back at the command prompt.  I tried it again with the SP3 CD.  Same result.  Apparently I had mistyped the command previously.

I thought maybe I could run winnt if I could find a 16-bit DOS equivalent.  My search led to FreeDOS, where I downloaded FDFullCD.iso.  I burned it and booted the laptop with it.  I indicated that I wanted to boot FreeDOS, and then chose option 3, FreeDOS Live CD with HIMEM + EMM386.  But I got this error:
Selected page frame e000 not available, searching automatically
No suitable page frame found.  EMS functions limited.
I gathered that EMM386 was not a good option in this case.  I rebooted and tried again, this time choosing option 4, HIMEM only.  This produced a bunch of error messages, but at least it put me to an A: prompt.  Drive B appeared to be a RAM drive.  The program did not recognize drive C.  I thought this must be because it was an NTFS drive, but no, FreeDOS did not recognize any drive, including the CD drive.  I booted FreeDOS again, and this time chose option 5, FreeDOS Live CD only.  I still got some error messages, including "There is no CDROM, or the wrong CD-ROM!"

I guessed that whatever kept this CD-ROM drive from recognizing WinXP was also impairing its recognition of the FreeDOS CD somewhat.     In that case, I wondered if I could install the contents of the WinXP CD from a bootable FreeDOS USB drive.  To make that, I followed instructions to install Unetbootin on my Ubuntu machine, and then used Unetbootin to make a FreeDOS bootable USB stick.  When that was done, I checked its properties and saw that Ubuntu indicated the filesystem type was msdos.  I copied the /I386 folder from the slipstreamed WinXP SP3 CD to the USB stick, put the USB into the laptop, and rebooted.  After a Unetbootin screen, I was back at the FreeDOS menu.  I tried option 3; same errors as before.  I tried option 5.  This time, it recognized the USB drive as drive C.  Then I realized that this was no help; it still couldn't see the partition on the hard drive where I wanted to install WinXP.  Well, could I reformat that partition as FAT32?  I formatted another USB drive as FAT32, put it into the laptop, and rebooted from the FreeDOS stick.  It did recognize the FAT32 USB drive.  Now, could I install WinXP on a FAT32 partition?  It looked like it was supposed to be possible.  I pulled out the USB drives, rebooted the laptop with GParted, and replaced the NTFS partition where I had planned to install WinXP with a FAT32 partition.  (I figured this would be much faster than trying to convert from NTFS to FAT32.)  Of course, now I was wondering whether the FAT32 alternative would also have made a crucial difference with some of the attempts to install from UBCD.  When GParted was done, I rebooted with the FreeDOS stick.  Sure enough, now I could see the FreeDOS stick as drive C and the WINXP partition as drive D.  I tried using XCOPY, but it didn't work.  I wasn't sure how to copy subfolders etc. in FreeDOS.  Rather than research it, I removed the FreeDOS USB, rebooted with UBCD, plugged in the FreeDOS stick, found that WINXP was now drive C and the FreeDOS stick was drive G, and therefore used XCOPY G:\I386\*.* C:\I386 /E /H /Y to copy the I386 folder from the FreeDOS to WINXP.  This time around, that ran very smoothly.  I rebooted with the FreeDOS USB stick.  I went into the I386 folder on the WINXP partition (which was drive D in this case), and typed WINNT.  Windows XP Setup asked me where the XP files were located.  It defaulted to D:\I386, so I left it at that.  Next, it said this:
Windows XP Professional Setup
Setup did not detect SmartDrive on your computer.  SmartDrive will greatly improve the performance of this phase of Windows Setup.
You should exit now, start SmartDrive, and then restart Setup.  See your DOS documentation for details about SmartDrive.
I looked into SmartDrive.  Along the way, I ran across the ingenious suggestion that I could use an IDE to USB adapter and, with that, could use the internal CD drive on a desktop computer as an external drive for some other computer (if I had needed to do that).  (This would require leaving the CD drive's power connected in the host computer.)  SmartDrive itself was an MS-DOS disk cache program, to speed up file transfer times.  It appeared that FreeDOS might have its own cache arrangement, presumably faster if I could get HIMEM and/or EMM386 to load.  The best I could do was to reboot, choose FreeDOS option 3, ignore the FreeDOS boot error messages, and continue past the WinXP setup message about SmartDrive.  WinXP setup next said, "Please wait while Setup copies files to your hard disk."  It copied files for a while, and then froze.  I had heard something about how WINNT would only start the process, so I rebooted with UBCD, went into C:\I386, and typed "winnt32.exe /syspart:C: /tempdrive:C: /makelocalsource" and, this time, it worked!  It gave me "Welcome to Windows Setup" and then asked for my WinXP's product key.  I went through the various options, accepting the defaults (including the offer to upgrade my drive to NTFS), and it began the installation process.  It estimated that it would take 52 minutes, instead of the usual 39.  But then something happened.  I turned away, and when I looked back, we were back at the UBCD prompt.  I ran WINNT32 again, just like before, but this time I said No to the option of upgrading to NTFS.  It didn't matter.  I ran it a third time, and again it crashed, shortly after it finished "Copying Installation Files."  No error message or anything.  I rebooted UBCD and tried installing again from the I386 folder that I had added to the bootable FreeDOS USB drive, using the command "G:\i386\winnt32 /syspart:C: /tempdrive:C: /makelocalsource" (because G was where the system saw the FreeDOS USB drive).

So now I wondered whether I could boot to a very WinXP-compatible 32-bit command line.  I started with Vista.  My Vista installation was not booting at this point, probably because I had told GParted to hide the Vista partition, so I inserted the Vista DVD and rebooted.  I went with its Repair Your Computer option but didn't proceed with the repair, choosing instead the steps necessary to get a command prompt.  I inserted the FreeDOS USB and found it at drive H.  But before trying it, I went to C:\I386 and ran that WINNT32 command again.  It proceeded just as it had done in UBCD, except I didn't recall having to agree to the license agreement in the UBCD process.  It crashed -- it put me back to the command line -- just as it had done in UBCD.  I tried again, this time starting from the I386 folder in the FreeDOS USB.  I even swapped out the Vista CD for the WinXP CD, just in case that would make any difference.  It didn't.  Another crash.  I took out all bootable items, rebooted, and got "Disk error.  Press any key to restart."  So, no, it had not by some magic completed the process.

I rebooted UBCD.  On another computer, I copied C:\Windows\system32\chkdsk.exe to a new Utilities folder on the FreeDOS USB.  I plugged in the FreeDOS USB, navigated to C:, and typed D:\Utilities\chkdsk /r.  It ran.  I told it to force a dismount.  It quickly checked files and slowly checked free space.  It found no problems.  I rebooted with GParted and had it check the filesystem on the WINXP partition.  No problem there either.  I wondered if the presence of even a hidden Vista partition was screwing things up for WinXP.  I deleted both partitions and recreated WINXP.  The WinXP CD would still not boot.  The Vista CD would still boot, and it gave me a command line from which I could run winnt32.  Even so, it crashed again.  I wondered whether the problem was with my SP3 CD.  I made another folder on the FreeDOS USB, naming it I386-SP2, and copied the I386 folder to it from the WinXP SP2 CD that I had used in making the SP3 CD (i.e., having the same product key).  I tried running WINNT32 again from the Vista command prompt, using this I386-SP2 folder as the source.  This gave me an error:
Setup was unable to build the list of files to be copied.
The system cannot find the path specified.
I verified that the WINXP partition was still drive C, and that it contained an I386 folder.  The problem seemed to be that the I386 folder has to be named I386 -- nothing more, nothing less.  I renamed I386-SP2 to be I386 and re-ran the WINNT32 command.  It crashed again, in exactly the same way as before.  I checked C: to see what WINNT32 was actually doing there.  The answer: not much.  It was creating files named $WIN_NT$, with the extensions .~BT and .~LS, along with a file named textsetup.sif, and it had copied NTLDR over.  And that was about it.  I deleted those $WIN_NT$ files and tried WINNT32 again, this time using the product code from my other WinXP CD.  It crashed, of course.

Someone said that a problem something like this one sounded like it might be due to a bad CPU or other hardware.  Of course, that was always possible.  I wasn't ready for that yet; after all, everything else seemed to work OK.  But I was running out of other theories.  Then I stumbled into a search from which I gathered that "downgrade" was an official searchable term, especially where Vista was concerned.  PC Magazine had a two method article, but neither method would work for me since I wasn't able to boot from the XP CD.  I found what looked like the consummate downgrading guide, with specific information for my laptop model.  For a CQ60 with an Intel CPU, it seemed to say that I should slipstream the ICH9 SATA driver (ICH9M-E/M SATA AHCI Controller) into the XP installer using nLite.  To get the ICH9, I downloaded and unzipped f6flpy3289.zip, but I did not understand why the highly regarded CherylG was telling me that I would find my driver inside iaAHCI.inf.  In the process of digging around for the driver she named, I contracted a virus, which prompted me to get up-to-date on Spybot Search and Destroy and on the Web of Trust add-on for Firefox.  I eventually found the driver on an HP webpage (though not the downloads webpage for my laptop).  I ran it on another computer (it was an .exe file) and it tried to install itself but then said the computer didn't meet the requirements, which I assume meant something about its particular CPU.  The conclusion there seemed to be that it would help to run it on a computer whose hardware was very different from the target computer, so that it would just extract but would not install.  I didn't know if it would run on the laptop from the Vista prompt, but anyway this was not the concept of slipstreaming, so I went back to the first one that CherylG had pointed toward.  Then I downloaded nLite and looked at the recommended guide for slipstreaming the driver.  Now that I saw the guide, I understood why CherylG was pointing me toward an .inf file.  She apparently didn't mean that I somehow had to extract the driver from iaAHCI.inf; I just had to include that .inf file in the slipstream.  This seemed to be the only thing I had to slipstream, so I went ahead with it.

The slipstreaming process began by copying the entire SP3 CD to a folder on the hard drive that I called SP3CD.  I started to install nLite, which required the Microsoft .NET Framework 2.0.  Installing that required trying to update .NET Framework 1.1 and then downloading a tool to uninstall it when the updates failed, and then manually doing registry edits etc. to uninstall it when the tool failed.  That ran overnight.  Next morning, when that was done, I followed the MaxEasyGuide to slipstreaming with nLite.  The first time, for some reason, it did nothing.  Second time, it made a file that I called SP3-SATA.ISO, containing the ICH9M-E/M SATA AHCI Controller driver from within iaAHCI.inf -- and now I understood what CherylG was saying.  Next question:  what was I supposed to do with this thing?  I decided to open it with UltraISO and copy its I386 folder to another folder.  Then I ran Beyond Compare to see how different it was from the original slipstreamed SP3 I386 folder.  It looked like there were a couple dozen differences in files.  So, OK, the nLite process seemed to have done something.  I wasn't sure I had done all of these steps right, but I decided to give it a shot.  I used Beyond Compare to synchronize the I386 folder on the FreeDOS USB with the I386 folder I had just extracted from SP3-SATA.ISO.  Whoa.  Many, many differences.  I forgot -- I had been using the SP2 I386 folder.  I changed that around and re-ran the comparison.  Still tons of differences!  Oh, I knew why.  It was because of the timechange.  The files were mostly the same, but some had been created an hour before the others of similar name.  I told Beyond Compare to ignore unimportant differences and did a full refresh, but that made no difference.  I bit the bullet and upgraded 6,992 files on the FreeDOS USB.  While that was underway, I re-ran the nLite and Beyond Compare processes, just to be sure.  Everything looked good.  I put the updated FreeDOS USB drive into the laptop and re-ran the WINNT32 command.  Alas, that wasn't the answer.

I found another thread that seemed to say that CherylG's advice on drivers was for an AMD CPU, whereas my CQ60-420US had an Intel CPU.  But some respondents said they were definitely using the Intel drivers and it still wasn't working.  Unfortunately, the drivers they pointed to were no longer availlable at the Intel website.  Daniel Potyrala advised that I download and run CPU-Z in order to find out not only my CPU type but also my chipset.  I couldn't very well run CPU-Z without an operating system.  Since it seemed that having Vista on the same hard drive did not explain why I could not even run WINNT32, it seemed to be time to restore the Vista partition using GParted and Acronis.  Adam Pash assured me that it didn't matter which came first, WinXP or Vista, so I left the WinXP partition in place (in hopes that it would someday be operational) and just added the Vista partition behind it.  I downloaded the appropriate version of CPU-Z, jumped it over to the laptop, and installed and ran it.  CPU-Z said that my mainboard chipset was an Intel GL40, which meant that I needed to slipstream . . .  the ICH9M-E/M SATA AHCI Controller driver, just like before.  So Mr. Potyrala was wrong; CherylG had given me the right tip.  But then Fernando1 said there were different drivers for 32-bit and 64-bit CPUs.  My T4200 Pentium (Penryn) was a 64-bit.  It was hard to tell the two apart; the driver names were the same.  I repeated the nLite process.  This time, the Textmode driver I selected was the ICH9 SATA AHCI Controller (Desktop ICH9R).  There were, again, some differences, so once again I updated the FreeDOS USB drive and tried it in the laptop, this time typing  "I:\i386\winnt32 /syspart:F: /tempdrive:F: /makelocalsource" because the FreeDOS USB was at I: and the WinXP partition was now at F.  That didn't work, so I tried once more, this time selecting the ICH8R/ICH9R SATA RAID Controller.  That didn't work either.

It was time to quit.  The webpages to remember, for future reference, included Quang Do's post in an HP forum, listing drivers and their sources; ditto Riskyone101; and perhaps a post, by wimb, that I really didn't understand.  The approach to remember was to use Unetbootin in Ubuntu to quickly create a FreeDOS bootable USB drive, if I needed 16-bit support, or just a Vista DVD or UBCD, if I could go straight to 32-bit support; to format the target drive in FAT32 rather than NTFS if necessary; to use nLite to create a slipstreamed ISO, assuming I could find the right drivers, and UltraISO to extract files from that ISO to load via USB drive if necessary.  I didn't know why WinXP could not run on the laptop, and I wasn't sure what else to try at this point.