Mindi Fails to Create Boot Disk When -T Specified

[SamK]

mindi-busybox_1.18.5-2 mindi_2.1.2-1 mondo_3.0.2-1

When Specifying a backup that includes the -T switch mindi begins to collect the files for the boot disk but fails to complete. It is seen when creating both local and nfs backups.

Example 1 mondoarchive -O -n nfs://192.168.2.104: -d /mondo -p mondoverass -G -4 -s 4480m -T /tmp -N -I "/bin" -E "/home|/mnt/nfs" See: mindi.log.fail.nfs mondoarchive.log.fail.nfs

Example 2 mondoarchive -O -i -d /var/cache/mondo -G -4 -s 4480m -T /tmp -I "/bin" -E "/home|/mnt/nfs" See: mindi.log.fail.local mondoarchive.log.fail.local

[SamK]

Correction to typo in Example 2 As reported -E"/home|/mnt/nfs" Actually used -E "/home|/mnt/nfs"

Also I thought it might be helpful to compare the logs of the same backup successfully run without the -T switch.
Example 3
mondoarchive -O -i -d /var/cache/mondo -G -4 -s 4480m -I "/bin" -E "/home|/mnt/nfs"
See: mindi.log.success.local mondoarchive.log.success.local

[Bruno Cornec]

I've fixed a bug recently happening only in certain circumstances with a similar behaviour (Cf: #689)

You could check that the same solution works for you applying the corresponding patch, or give me the distribution/version/arch you run so I can generate packages for you to try.

[SamK]

Replying to bruno:

I've fixed a bug recently happening only in certain circumstances with a similar behaviour (Cf: #689)

You could check that the same solution works for you applying the corresponding patch, or give me the distribution/version/arch you run so I can generate packages for you to try.

I prefer to test packages rather than patches. System is Debian 6.0 Stable i386.

[Bruno Cornec]

It's now available at ​ftp://ftp.mondorescue.org/test/debian/6.0/mindi_2.1.520130524115715-0_i386.deb (Sorry wrong version I should update my changelog to get the 2.1.6 track in it).

[SamK]

Versions Tested:
mindi-busybox_1.18.5-3_i386.deb
mindi_2.1.520130524115715-0_i386.deb
mondo_3.0.3-1_i386.deb

TEST1
Command Issued:
mondoarchive -O -i -d /var/cache/mondo -G -4 -s 4480m -S /tmp -T /tmp -I "/bin" -E "/home|/mnt/nfs"

Result:
Mindi boot ISO produced as /var/cache/mindi/mondorescue.iso
Mondo backup ISO produced as /var/cache/mondo/mondorescue-1.iso
mondo.scratch.xxxxx is not removed from /tmp
mondo.tmp.xxxxx is removed from /tmp

Logs Attached:
mindi.log.cli.local
mondoarchive.log.cli.local

TEST2
Command Issued:
mondoarchive -O -n nfs://192.168.2.193: -d /mondo -p mondoverass -G -4 -s 4480m -S /tmp -T /tmp -N -I "/bin" -E "/home|/mnt/nfs"

Result:
Mindi boot ISO produced as /var/cache/mindi/mondorescue.iso
Mondo backup ISO produced on remote 192.168.2.193/mondo/mondoverass-1.iso
mondo.scratch.xxxxx is not removed from /tmp
mondo.tmp.xxxxx is removed from /tmp

Logs Attached:
mindi.log.cli.nfs
mondoarchive.log.cli.nfs

SUMMARY
mindi_2.1.520130524115715-0_i386.deb fixes the reported bug
An attendant issue is now seen i.e. the failure to remove mondo.scratch.xxxxx
The resulting ISOs were not tested for boot/restore

RELATED TICKET
#640 mondo.tmp.xxxxx & mondo.scratch.xxxxx Issues

[Bruno Cornec]

So I'll close this bug as fixed and work on the other one reported as #640 wrt temp/scratch dirs.