Re: [Announce] BackupMenu - OS backup & restore | New version - Jul 9th(v1.1)
 

hi all,
thanx for the great app :)
i got a problem tomorrow.few weaks ago,it was working perfect but tomorrow i dont know what happened now,whenever i tried to backup Rootfs it gives me a same error again & again.
error: /var/tmp/qtsingleapp-sticky-28d2-752f : socket ignored

tried reboot several times but no luck.help required please....

regardz,

Re: [Announce] BackupMenu - OS backup & restore | New version - Jul 9th(v1.1)
 

Why do you think it is problem? Just finish backup, and it will work.

It was discussed some times ago, as chromium cause same issue. normally, applications shouldn't leave sockets opened, so it's fault of corresponding program (qtsingleapp? WTF is that?). But, it shouldn't affect Your backup in any way, it's just warning.

/Estel

Re: [Announce] BackupMenu - OS backup & restore | New version - Jul 9th(v1.1)
 

ok thanx.
first,that had never gave me such error.
so according to you i should ignore this?

Re: [Announce] BackupMenu - OS backup & restore | New version - Jul 9th(v1.1)
 

Yes, in context of backupmenu.

OTOH, You may want to investigate it for sake of offending program, as it's clearly malfunctioning, and leaving things (that it shouldn't) open. But it's not relevant for backup.
---

Slightly different topic - robbiethe1st, some time ago I've sent You patches for backupmenu, that allowed to use tar.lzma over .tar.gz for compression (much better results), + we've discussed using bq2415_charger module for charging, in case of kernel-power users.

Any progress on implementing it for new version? Or You have met some roadblocks?

/Estel

Re: [Announce] BackupMenu - OS backup & restore | New version - Jul 9th(v1.1)
 

btw m not a programmer nor developer,so how can i investigate :confused:

Re: [Announce] BackupMenu - OS backup & restore | New version - Jul 9th(v1.1)
 

I have just restored a backup from two days ago using backupmenu 1.2 (both rootfs and ext3 eMMC). It worked flawlessly, but now I have about 13 Mb less disk space in the rootfs. What could be the problem? Any temp file that I can delete? I am sure that I had about 72 Mb free on rootfs and now only 58 Mb.

Thanks.

Re: [Announce] BackupMenu - OS backup & restore | New version - Jul 9th(v1.1)
 

Using common sense. Given name of socket left open (it's location), you should be able to pinpoint program that left it open. If You keep trace of what You've installed on Your device, that is.

/Estel

Re: [Announce] BackupMenu - OS backup & restore | New version - Jul 9th(v1.1)
 

ok :p
i've opened that location (/var/tmp) before posting here,there were two files named:
qtsingleapp-sticky-28d2-752f
qtsingleapp-sticky-28d2-752f-lockfile

may be something went wrong if i delete them.....
i should delete them or not?
btw i already have backup & thanx for the reply :)

Re: [Announce] BackupMenu - OS backup & restore | New version - Jul 9th(v1.1)
 

I've been reading the whole thread (enormous!!!) and I've seen that some people were dealing with this problem related to the ubifs compression. That was one year ago, for backupmenu version 0.6 and so. Was this problem fixed? Do I need to select the image compression when doing the backup and then the restore is smaller in rootfs?

Re: [Announce] BackupMenu - OS backup & restore | New version - Jul 9th(v1.1)
 

@ikerrg,

Just an idea (I don't use backupmenu). Depending on how backupmenu is packing the rootfs it may be that the backup contains parts of the filesystem that shouldn't be there.

An example: /tmp is a RAM disk. If backupmenu includes /tmp in the rootfs backup, then when you restore the image it will restore the /tmp directory on-disk. Later when you boot /tmp will be mounted as a RAM-disk, meaning your on-disk /tmp will be "hidden" underneath the mounted /tmp.

I suppose that the above is not actually happening with backupmenu. It would be seriously sloppy to backup a filesystem by including parts of other file systems (option "--one-file-system").

Just in case, I'd suggest you inspect the backup image created by backupmenu and check if there is something there that shouldn't be.

*** Update: I just checked a .tar image I happen to have here, and it looks OK.

Re. UBIFS compression. Sounds plausible enough. There may be a significant difference in the overall compression ratio depending on the other in which the files are written to the file system. One could try experimenting with this by splitting the .tar image into separate images (one with binaries, one with text files, etc.) and then unpacking them one after the other (each time in a different order), and see the effect this has (if any :) in the overall compression ratio for the whole rootfs.