Menu

Less than 2MB [zip...internal logic error]

b0bcat
2001-05-19
2001-05-30
  • b0bcat

    b0bcat - 2001-05-19

    I posted on the Help forum but it's rather quiet round there.  Always thought that replying to your own posts was about as solipsistic as pulling a Christmas cracker with yourself, but here goes, in case anyone has workarounds or thoughts or indeed if this helps anyone.  I noticed Rene's page is updated last in March 2001 but it also says he's busy completing his PhD so I haven't mailed him ...  I may post on comp.sys.palmtops and comp.os.linux.misc and see if anyone has ideas.

    As per my post on the Help forum I experienced a zip logic error ["zip error: internal logic error (write error on zip file).  Backup completed"] when trying the automated backup of a Palm IIIe with 2MB RAM, about 95% full.  I am a Linux novice so am groping at the cause(s) but my suspicions lead me to the tentative conclusion that (a) the compression step in the backup process may need more space than the ramdisk can allow in addition to letting the files from the Palm sit there and (b) the floppy disk being backed up to if in standard MSDOS 1440k format may be too small to take the zipped but still engorged content of one's overloaded Palm ;-)

    1.    Penguinbackup version 2 seems to mount one 4 MB ramdisk (or is it 2?  I noticed mount gives output referring to 2 ramdisks but both mounted on / and having the same device name).  About half of the ramdisk is taken up with the mini Linux system presumably decompressed off the boot disk (I haven't been able to mount the boot disk itself under any conditions including Vector Linux 1.8 and assume it must contain some sort of compressed image going beyond just a compressed kernel).

    2.    using the menu system under the above conditions led in my case to perfect communication at 57600 with the Palm and apparent backup activity with a clean manifest ... but no writing to the floppy.  After the pilot-xfer had done its stuff the floppy started to churn and after a few files the zip logic error came up; thereafter success reported and activity ceased.  Nothing was written to the floppy.
    From this I deduce that (a) the ramdisk space left is not enough to copy the files in pilot RAM (perhaps but no error message from pilot-xfer so maybe not) and/or (b) the temporary space required by the zip file creation process just wasn't available.

    3.    I tried working round lack of temp space by (i) mounting additional ramdisk but couldn't do so as no mkfs.ext2 or kindred means that I can see of making a filesystem is on the system loaded by version 2 of the application; (ii) selecting temp space in zip command line (-b) to use space on the destination floppy (which didn't work either).

    By now I as doing a bit of typing and found it rather more arduous than usual as the command line recall of arrow up seemed to be broken, at least on my machine (US keyboard).

    4.    I then downloaded and ran version 1 of the software off sourceforge (ftp://penguinbackup.sourceforge.net/pub/penguinbackup/).  It has no menu system but like version 2, boots very quickly.  However it does have a functional command line recall, again at least on this machine.

    It also has mkfs.ext2 and associated libraries on it but gzip and tar, not zip.  Anyhow, mount showed *one* 4MB ramdisk mounted on / and this was about half full.  I created two additional ramdisks (one e.g.):

    mkdir /mnt/ramdisk2
    mkfs.ext2 /dev/ram2 [or whatever the file name was - can't recall exactly right now!]
    mount /dev/ram2  /mnt/ramdisk2

    5.    having got plenty of space I then did pilot-xfer and backed up to the second ramdisk without compressing.  All fine.  Next thing was to compress, using the third ramdisk as the temp space and location of the compressed file before copying it to floppy.

    6.    at this point I found the second potential space constraint - the floppy.  I compressed the files on the second ramdisk into a tgz on the third ramdisk and then tried to copy that to the floppy.  No success.  Reason: floppy being MSDOS formatted had 1440k space whereas even the compressed pilot-xfer backup file was about 1650k.  So save failed.  Most of the space taken up on my Palm IIIe is not .prc executables but doc .pdb databases and these evidently do not compress much as per the filenotes (about 10-15%?)

    Faced with this problem I then fdformatted to 1722k another floppy and created an ext2fs file system and mounted that.  Eventually got the tgz copied to it.  Grateful that the command line recall worked at this point!

    fdformat /dev/fd0u1722
    mke2fs -b 1024 -m 0 -L palm3data-1 /dev/fd0u1722

    7.    the workarounds for all this to me (novice I repeat) using the Palm IIIe with 2MB RAM seemed only:

    (a)    don't use all the Palm's memory but put .pdb documents on a floppy and load them to the Palm using Penguinbackup version 2 as and when required.  I haven't yet tried backup under the menu with say 2/3 or less memory full on the Palm but assume it should work.

    (b)    use version 1 of the software (so you can create more ramdisks for the copying and compressing steps) and create a 1722 extfs floppy to take all the single compressed backup file.  But to me the backup is more clunky as you have to use gzip and tar rather than zip as the latter isn't on the disk but a matter of personal taste

    I reckon the menu front end on version 2 is rather nice and indeed works well for me (particularly on setting serial port speed tho' working to see how to get it to run to double 57600) apart from the space constraint issues and the command line recall thing.  Hence I wondered if I could not just take the version 2 software and add to it mkfs.ext2 and the associated libraries and maybe try and fix the command line / termcap on version 2 and see if I got the best of both worlds.  Unfortunately as I say I couldn't mount either of the boot disks so assume they are fully compressed image only and I haven't the first idea of how to take the kernel image, boot loader and everything else in PenguinBackup.tar.gz, add the mkfs.ext2 etc files to it and create an updated boot floppy (despite a quick scan of the Bootdisk How-To) - see http://penguinbackup.sourceforge.net/contents.txt.html for file listing.  Has anyone any idea how to do that?  The error messages on trying mtools were [minfo a:] "init A: unknown media type / Cannot initialise A:" and on trying mount: "block device /dev/fd0 [others tried and same result] is write-protected, mounting read-only [but nothing visible in mount point].

    8.    Dunno if this will help anyone (hopefully me included :-)  ) but the lack of space on ramdisk and/or floppy might account for my travails as well as of one or others who have failed so far with the program like the one below
    <<
    http://www.eurocool.com/cgi-bin/palm/action.cgi?dataset=listapps&appid=7634&action=showreviews
    I'd like to rave, but I have a IIIx (and am using under 2 meg of memory), and I download PG, and when I used it, I got error messages regarding invalid filesystem type, and there was no apparent zip archive actually created on the diskette. This, in my view, is worse than an outright failure (say a crash) during backup because one might think (incorrectly) that the backup has occurred correctly. 
    Sam K [name/email address snipped]
    >>
    9.    so to recap the main issues I can see: maybe a fix available by creating an updated boot disk of version 2 but (i) with mkfs.ext2 and libraries on it; (ii) fix the termcap problem on version 2 bootdisk (I have no clue how to do that and why version 1 works for me and not version 2).

    Cheers and thanks to the author for this software which I particularly like because it presents an elegant and practical solution to a practical problem - how to be able to back up and restore the Palm RAM without needing access to a PC with W95 and the hotsync etc stuff on it AND extend the range of the Palm by having unlimited storage on floppies for books etc etc.

    rgds

     
    • René Witte

      René Witte - 2001-05-30

      Wow.  Ok, you are now probably more experienced with PB than I am, but I'll try to answer some of the questions anyway... :-)

      As for the zip "internal logic error", I'm not sure.  It suspect it is a "out-of-memory" error rather than a "floppy full" problem, but I haven't seen this yet.

      The standard PB only has one ramdisk with 4MB, which leaves about 2MB after booting for backup data.
      I now have (with the kind help of other developers) some versions with patched ramdisks, so that you can get 8 or 16 MB.  I think I'll post these here; this should help someone like you until the new automated version is finished (for some of the problems with this, check the other threads).

      PB v2.0 doesn't have the necessary tools for creating a new ext2 filesystem (they were dumped due to space constraints).
      As you discovered, v1.0 still has them.  You can also download them for v2.0 from:
      http://wwwipd.ira.uka.de/~witte/pilot/backup/ext2.tar.gz
      (undocumented feature :-)

      If you have enough floppies, you can easily create a multi-floppy backup with tar like this:
          tar cvMf /dev/fd0 <backup_dir>
      This will prompt you to swap floppies once one is full. Note that this won't compress the archive! (also see the other thread on this problem).  To restore, also use the -M option.

      Finally, you can use v2.0 for *restoring* more than 2MB --- just create a full backup on your PC (with the pilot-link tools) and split it manually over several floppies (zip format).  You can then use PB to restore the backup, one floppy after the other.  Creating a full backup on the road is, as you discovered, still rather cumbersome.

      Cheers, Ren

      PS: Oh yes, the shell thing.  v2.0 uses ash, which is much smaller than the bash used in v1, but doesn't have the command line recall ability...

       

Log in to post a comment.

MongoDB Logo MongoDB