Help with pax.

Question

Level 1

79 points

Help with pax.

Appologies for the re-post. I posted this on the Tiger Install and Setup forums, but it didn't illicit a response. I guess this might be a more appropriate place to rant...

I have a dead system due to 10.4.6 failing mysteriously. I'd like to get my system back, and as apple don't want to help users, maybe someone here can answer a few questions, which might help.

Before going to work, I set SU to downaload and install the update. When I got home I discovered the install failed, and from then on in, all commands run in my open terminal failed. Reboot fails with error 88 on launchd. DiskWarrior didn't find anything significant.

Booting from the OSX DVD allows me to look at the drive, all looks ok. I can't run anything in a chroot'd environment on the cd, this seg faults, has an illegal instruction, or bus error. I thought I could manually look at the apple package format and do it myself... however, trying to extract the Arichive.pax file is giving me issues.

In an act of amazing stupidity, /tmp isn't a shared memory device under the OSX boot cd (WHY?!? Look at any other unix vendors boot cd, and they at least allow you to write to /tmp, as that pretty useful for a lot of commands... like pax). Now, in another act of stupidity, no man pages are installed... so I dug around on the net for pax man pages. I found that some versions of pax honour the TMPDIR variable... but hey, not apple's... Nor can I find any switches to tell it to use /Volumes/Macintosh\ HD/tmp (which is writable) rather than /tmp (which is moronically read only).

Does anyone have a solution to coaxing pax not to use /tmp. As I've said, I can't run anything in chroot due to what I expect is library corruption. Is there any alternative to the OSX boot DVD, as it's really badly implemented?

I want to look at the files it's got in that Archive, compare with what's on my system, and try to track down where the problem occured.

Thanks for any help.

Mac Mini, Mac OS X (10.4.5), It's Borked due to a failed 10.4.6 upgrade... Thankyou apple.

Posted on Apr 6, 2006 7:59 AM

Reply

Answer 1

Anachronism Author

Level 1

79 points

Apr 6, 2006 10:15 AM in response to Anachronism

Ok, no response... time for plan b. I could make a subdir on the hd, copy the entire boot dvd environment into it, and the pax file, I should be able to chroot into it (aslibraries should be ok)... I should then be able to extract the pax, and go from there. Its a clunky solution, but it might just work. 😟

Reply

Answer 2

Apr 6, 2006 4:52 PM in response to Anachronism

Archive.pax.gz

to list the table of contents.

%pax -z -f Archive.pax.gz | more

In my case, all of the paths listed started with './' which
tell me that if I extract the files, they'll be placed in the
current working directory. so to extract

pax -rzf Archive.pax.gz

if the listing doesn't show all paths starting with './' then you'll need to use
the '-s' option. There's an example on the manpage.

Reply

Answer 3

Anachronism Author

Level 1

79 points

Apr 7, 2006 4:14 AM in response to Nils C. Anderson

Thanks, but the problem is, when you boot from the MacOSX dvd, /tmp is (majorly stupidly) read only. Pax fails if it can't write temporary files to /tmp. I need(ed) a way of persuading pax to not use /tmp. One sensible way would be if pax honored the TMPDIR environment variable, then I could point it elsewhere. But it doesn't. Another solution would be to do it from your HD chrooted, eg chroot /Volumes/Macintosh\ HD /bin/bash, however the failed upgrade had knackered my system such that I could not do that (seg faulted). My eventual, really nasty work around was to create a miniroot dir in /Volumes/Macintosh\ HD, copy into it /bin, /usr, /sbin and /var (for good measure), and make a tmp dir in their, then chroot /Volumes/Macintosh\ HD/miniroot /bin/bash. From there I could run PAX, as /tmp was writeable. From there, I was able to resurect my dead mini after it's failed 10.4.6 upgrade.

It wasn't pretty, but it worked. It really made me wonder about apple's patching process though. I had a .pkg with an Archive.pax.gz file, which had corrupted/truncated files in it, but was still a valid gz file, and valid pax (normally if your truncate a gz file, it's no longer a valid gzip file). The fact that the pre-install script didn't checksum this file before install is also an unforgivable lapse by apple.

I ftp'd down the patch again... extracted the pax in my miniroot, from outside my miniroot, copied everything in (yeah, another *****, no man pages on the boot DVD env, so I couln't look up the cp switches to preserve permissions and links etc... in the end I kludged it buy running "tar -cf - * | tar -xf - -C /Volumes/Macintosh\ HD/". Not elegant, but preseved sym links, and permissions. Once that was done, I could run a chrooted bash on the HD mount without seg faults 🙂. Out of the chrooted env however, I ran installer -pkg <package again> -target /Volumes/Macintosh\ HD/ and all was well with the world again.

A real eye opener into how poor the Mac recovery environment can be though... and I am still concerned as to how the pax file could be come corrupted, and still be a valid archive... not to mention why apple's scripts didn't do a basic, best practice checksum test on the archive. I have included the md5 of my broken upgrade archive in the post I made in the upgrade/setup forum, and would like to hear from others who had a failed install what the md5 on their file was. I wonder if apple had a dodgey version on one of their akamai servers. The reports of dead machines seems to be tailing off, so I can't help but wonder if a dodgey install has been quietly pulled, maybe I'm just not trusting enough, and too paranoid...

Reply

Answer 4

Apr 7, 2006 4:34 AM in response to Anachronism

You might have a Hardware-problem with your RAM Modules.
I had the same case you currently have:
Automatic Software update failed, machine does not start.
mysterious errors when executing programs.

Automatic software update does not verify the contents of the Archive. This only happens, if you D/L an update manually using a .dmg. This contains checksums which can be veryfied.

Before doing anything else, boot from the Service CD and execute the Hardware-check.

Reply

Answer 5

Anachronism Author

Level 1

79 points

Apr 7, 2006 4:54 AM in response to nobody loopback

I will look into that, however I have seen no other problem that wold indicate a memory issue, everything was fine untll the upgrade failed.

Thanks for your response.

Reply

Answer 6

Apr 7, 2006 8:23 AM in response to Anachronism

"Installer should verify checksum of the archive before installing" sounds like a reasonable feature request. Tell Apple about it.

Dual 1.25 GHz G4 (among others) Mac OS X (10.3.9) Fink (obviously)

Reply

Answer 7

Apr 7, 2006 2:02 PM in response to Anachronism

Why use PAX, are you sure it will preserve all the information?

Use Apple's ditto tool and you may save yourself two problems in one.

Reply

Answer 8

Anachronism Author

Level 1

79 points

Apr 7, 2006 4:17 PM in response to Redwoodtree

Erm, because apple's 10.4.6 upgrade contains a pax file. This whole thread was because I wanted to extract libraries, etc from this upgrade on a dead mac. Why do you think pax won't preserve file information?

The basic problem was: Apple release patch, contains pax, kills machine, want to extract pax on machine from boot dvd. Boot dvd is "broken" as /tmp is read only. I've since posted the work around I used, however, would be interested if there is a neater way to get pax to extract using an alternate /tmp directory.

Reply