In following the Manual ('By Hand') Installation method described in the Handbook, It seemed to take a very long time or maybe for ever performing the lzma step to decompress the root filesystem.
I found that this alternative works better : any comments?
instead of the following three commands:
cp /media/cdrom/boot/rootfs.gz /mnt/target cd /mnt/target lzma d rootfs.gz -so | cpio -id
do this:
cd /mnt/target ln -s /media/cdrom/boot/rootfs.gz rootfs.lzma lzma d rootfs.lzma -so | cpio -id
I thought I had tried that and found that it failed trying to write a file rootfs.lzma onto the ro /media/cdrom/boot.
But I just tried again to check - and your suggestion works (with /dev/shm instead of /mnt/target). I must have made some mistake at the time. Thanks for pointing it out.
Anyway, a question - why is rootfs.gz named rootfs.gz and not rootfs.lzma?
*I* do not want to write to /media/cdrom/boot. In my earlier test last Saturday, I tried what you suggested (since it's the most obvious) and it did fail, and my quick diagnosis was that *it* (the SliTaz version of lzma) had been trying to do some kind of unpacking or transformation of the rootfs.gz in that directory where that file was located, i.e. /media/cdrom/boot. And I concluded that the task could not be done that way. I formed the opinion that somehow it was sensitive to the suffix of the input file. So I came up with the symlink idea, which worked.
Today I tried again the same test except I did not want to repeat exactly as before because (if it had worked successfully) that would have overwritten my root filesystem. So I modified the test to write to /dev/shm instead of /mnt/target. There should be no difference in result other than where the rootfs is unpacked to. And this time it worked.
So I think I must have made some mistake on Saturday and your suggestion should work fine.