Problems with filetool.lstForum: DSL Embedded Topic: Problems with filetool.lst started by: ngmlinux Posted by ngmlinux on Jan. 29 2006,18:18
I carefully read the instructions under "Saving Your Configuration" in the DSL documentation. I was very dissapointed to find things did not work the way they are supposed to with regards to .filetool.lst.I added some entries to .filetool.lst and after rebooting, not only where the settings / files that I wanted to keep gone, the entries I added were no longer listed in .filetool.lst. Either the documentation here is incorrect, something is wrong in v2.1, or I am missing something? Does anyone have a workaround solution for this issue? I'm basically just trying to get a few files and settings to persist. Additionally I have been unable to edit the Read-Only cis file /etc/pcmcia/cis. I have had no luck in making that a writable file. chmod did not seem to help. Any ideas? Posted by mikshaw on Jan. 29 2006,21:50
Make sure you specify a writeable partition for backup ("System -> Backup/Restore" in the fluxbox menu).Make sure that home/dsl/.filetool.lst is itself included in the list. Some files will not restore...files in /usr, /bin, /sbin may not restore, depending on how your system is set up. Chmodding system files just so you can write to them is a bad idea. File permissions do not apply to root, and system files should not be writeable by non-root users. /etc/pcmcia/cis might be a symlink to /KNOPPIX/etc/pcmcia/cis. If this is the case, you will need to delete the symlink and copy the linked file in its place. Posted by pr0f3550r on Feb. 21 2006,19:30
@mikshawI have a similar problem. After two months of successful use of Dsl I decided to experiment and I lost all my backups. Here's what I've done. 1) Mounted hdb 2) Run filetool.lua and instructed to backup to hdb 3) Open efelm and check if the backedup data are there: yes! 4) Shutdown qemu without a proper DSL shutdown 5) Restart DSL: backup is gone! What did I do wrong? I thought that at least hdb should have contained the previous backups. Instead if type:
and the shutdown Qemu (improperly) , the data _are_ backed up. Why doesn't it happen with filetools.lua ? Posted by mikshaw on Feb. 21 2006,20:00
The "without a proper DSL shutdown" could be the problem, but i don't really know much about the way embedded works. DSL backup is done during the shutdown process. If you just force kill the whole system there is no shutdown process, and therefore no backup.Another possibility is that the backup might still exist, but there is no parameter in the bat file to tell DSL to restore from hdb, so the backup file is just sitting there unused. All this is guessing, though...i have no experience with embedded (my first post was made without realizing which forum i was in). Posted by roberts on Feb. 21 2006,20:37
Why would anyone expect a backup to occur when they have aborted a virtual machine?Upon a normal shutdown, you will see, just as with any other version of DSL a system message saying... Backing up files to /mnt/hdb Done. Posted by ngmlinux on Feb. 22 2006,02:16
BTW, I have since resolved this issue, the only thing I was missing was to right click and navigate to the backup to option.In any case, I am still stuck on my pcmcia issue if anyone else wants to take a look. Posted by pr0f3550r on Feb. 22 2006,12:58
Why not? At the end of the day a virtual machine needs not be shutdown properly. By the way: a) 'sudo filetool.sh backup' does my job [EDIT: No, I realised it doesn't...] b) Maybe it's just a feeling, but it looks like it takes a second compared to 5 seconds with the proper backup, but I'll keep on experimenting Posted by roberts on Feb. 22 2006,16:01
I don't know what you are getting at!Of course one can do a backup anytime and anyplace with a manual sudo filetool.sh backup. So, is that your procedure do a manual backup and kill/abort Qemu? Do you do that for windows too? Or is this another Linux inside of Linux? Whats the point here just another thread to attack or argue? Posted by pr0f3550r on Feb. 22 2006,18:13
Don't understand. I presume you ask me if I shut down Windows from the power button, in this case the answer is no
Maybe you confuse me with the 'unregistered' troll who is targeting mikshaw in another thread. Posted by cbagger01 on Feb. 23 2006,17:28
I may be wrong, but if you push the "BACKUP" button on the Backup/Restore tool, does it immediately back up your files?
Posted by clacker on Feb. 23 2006,18:52
Actually pr0f3550r, it does need to be shutdown properly for the save to be complete. If you think about it, when you saved the backup you saved it to a virtual drive. That's great, but when does the virtual drive get saved? When you close the emulator correctly. So if you close the system down incorrectly or incompletely, the virtual drive never gets saved and your backup is lost. Posted by pr0f3550r on Feb. 23 2006,19:39
No, it doesn't. @clacker What you say makes sense and I am just experimenting. However the funny thing is that if I run: sudo filetool.sh backup when I boot again, some files sre backed up and some not. Looks like the proper shutdown backs up all the /home/dsl directory, but the manual backup doesn't. While I'm here I have noticed that the backup and restore process done from the *.iso image works much better than the standard embedded, that keeps on corrupting my dsl directory... Posted by roberts on Feb. 23 2006,20:11
Sorry, I cannot buy into this argument.Pushing the Backup button calls sudo filetool.sh So does the powerdown.sh, there is no difference between using the GUI or shutdown. Don't believe it, read the scripts! There is only one common backup/restore script which is used across all versions of DSL. You should at least post the size of virtual hard drive (using mount) and the size of your backup.tar.gz (using ls -l) and finally post the output of your /etc/fstab and /etc/mtab. What may be happening here is: 1. You have exceeded the size of the virtual drive. You can test this adding something to the filetool.lst Perform the backup and then tar -ztvf and see that it is there. 2. You may have doubly mounted the device. 3. You may be experiencing some Qemu issues with size and possibly order of the append clauses of the -kernel option, similiar to the Linux version of Qemu which I can see the inconsistency. If the -cdrom option to Qemu solves this, it would be nice to know. Especailly if a size issue is involved. I am most curious to see the sizes involved here. We need some way to duplicate your issue. |