This is the old SliTaz forum - Please use the main

manual installation onto HDD : improvement?
  • johnlumbyjohnlumby February 2011
    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
  • OldGuyOldGuy February 2011
    Why not

      cd /mnt/target
      lzma d /media/cdrom/boot/rootfs.gz -so | cpio -id

  • johnlumbyjohnlumby February 2011
    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?

  • OldGuyOldGuy February 2011
    You do not write to /mnt/cdrom/boot/, you read from it
    Why shouldn't the system read from a ro media?

    If I read you r message right, you write directly onto the device (/dev/shm) ans NOT to the mountpoint (e.g. /mnt/target) of that device?

    As for the name, I really don't know.

  • johnlumbyjohnlumby February 2011
    I didn't explain very well.

    *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.

    I hope that makes it clear?


Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

SliTaz Social