la discussion porte sur l'interface graphique qt-fsarchiver de Mageia 8
the discussion is about the Mageia 8 qt-fsarchiver GUI

Thank you for the report.
> After installing Magéia 8 qt-fs-archiver no longer works
This is confusing. It implies that qt-fsarchiver used to work, but does not now. Is this a system upgraded from Mageia 7 to 8 ?
Or did you install Mageia 8 normally, then add the program?

I have just installed it (pulled in a lot of other stuff). Cannot find it in the Tools menu, so from the command line:
 $ qt-fsarchiver
[asks for user password]
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'

[asks for SUDO password]
sh: line 1: /home//root/.local/share/.en.nfo: No such file or directory
sh: line 1: /usr/sbin/de: No such file or directory
chown: invalid user: ‘/root’
chmod: cannot access '/home//root/.config/qt-fsarchiver': No such file or directory

[then pops a small Note window saying: "The program qt-fsarchiver-terminal is not installed. You have to install this program additionally." OK that, it then shows the full GUI.]
rm: cannot remove '/home//root/.config/qt-fsarchiver/pid.txt': No such file or directory
rm: cannot remove '/home//root/.config/qt-fsarchiver/pid.txt': No such file or directory
[Exiting the GUI adds no further terminal O/P].

So is the complaint about these error messages, or that the program does not work? It does here, in spite of them.

Status: NEW => NEEDINFO
Source RPM: (none) => qt-fsarchiver-0.8.5.18-3.mga8.src.rpm
CC: (none) => lewyssmith

This package is completely broken due to an upstream source wrong structure. For me this package should be removed from repo! I tried to fix it but without real success.

CC: (none) => geiger.david68210

@Pierre
> is the complaint about these error messages,
> or that the program does not work?
Please reply, just so we know.
In the light of DavidG's comment above, this is likely to be closed 'wontfix'.
Can you sound out devs about removing it from Cauldron if it cannot reasonably be sorted?

Reporter, could you please reply to the previous question in comment 4? If you don't reply within two weeks from now, I will have to close this bug as WONTFIX. Thank you.

Keywords: (none) => NEEDINFO

I get same result as Lewis.

Yes, reporter: After the issues at launch, does it then execute OK? 

David G, do you think operating it propose any risk?
 If not I see no reason to drop it from mga8 repo.

 It seems to be a nifty program for people who prefer GUI.
 (i have only use fsarchiver from CLI)

CC: (none) => fri

systemd[1589]: Started Qt-Fsarchiver.
mai 08 14:36:20 localhost polkitd[933]: Operator of unix-session:c2 successfully authenticated as unix-user:aurelien to gain ONE-SHOT authorization for action org.fsarchiver.qt5 for unix-process:19333:44072 [/usr/bin/sh /usr/bin/qt-fsarchiver] (owned by unix-user:aurelien)
mai 08 14:36:20 localhost pkexec[19335]: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
mai 08 14:36:20 localhost pkexec[19335]: aurelien: Executing command [USER=root] [TTY=unknown] [CWD=/home/aurelien] [COMMAND=/usr/sbin/qt-fsarchiver]
mai 08 14:36:20 localhost qt-fsarchiver[19335]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
mai 08 14:36:21 localhost kernel: [drm:vmw_msg_ioctl [vmwgfx]] *ERROR* Failed to open channel.
mai 08 14:36:21 localhost kernel: [drm:vmw_msg_ioctl [vmwgfx]] *ERROR* Failed to open channel.
mai 08 14:36:30 localhost sudo[19372]:     root : HOST=localhost ; PWD=/root ; USER=root ; COMMAND=/bin/mkdir /temp1
mai 08 14:36:30 localhost sudo[19385]:     root : HOST=localhost ; PWD=/root ; USER=root ; COMMAND=/bin/rmdir /temp1
mai 08 14:36:31 localhost sudo[19393]:     root : HOST=localhost ; PWD=/root ; USER=root ; COMMAND=/bin/chown -R /root /home//root/.config/qt-fsarchiver
mai 08 14:36:31 localhost sudo[19403]:     root : HOST=localhost ; PWD=/root ; USER=root ; COMMAND=/bin/chmod 777 /home//root/.config/qt-fsarchiver

GUI seems to launch. It asks twice for root password or user password if member of wheel group.
It complains about missing qy-fsarchiver-terminal and ask user to install it.
Moreover, the gui is broken: it can't list existing partitions to save them.

Upstream https://github.com/DieterBaum/qt-fsarchiver is at version Version-0.8.5-21

Unsure if there is any improvements. Remark: upstream talks about Debian,Ubuntu, Linux-Mint, Suse and Fedora only for compatibility.

But according to:
(In reply to David GEIGER from comment #3)
> This package is completely broken due to an upstream source wrong structure.
> For me this package should be removed from repo! I tried to fix it but
> without real success.

We should remove this.

Keywords: NEEDINFO => (none)
Assignee: bugsquad => geiger.david68210
Status: NEEDINFO => NEW

Thanks Aurélien for your discoveries.

qt-fsarchiver-0.8.5.18-3.mga8
> Upstream https://github.com/DieterBaum/qt-fsarchiver is at version
> Version-0.8.5-21
This looks worth a try if not painful.
But not if the reporter continues his silence re comment 2

> upstream talks about Debian,Ubuntu, Linux-Mint, Suse and Fedora only
> for compatibility
Suse & Fedora are both rpm based, and we tend to follow Fedora; so we should not rule it out.

I have installed Mageia 8 as a new installation on one computer and on another as an upgrade from Mageia 7 and I encountered the same problem. The gui does not allow the selection of the partition to be saved or restored. Quite disappointing.

This an important program to be able to save and restore partition. Until fixed can someone at least provide a recipe on how to compile it from source? from sourceforge the recipe is not given for Mageia and the required components given for Fedora or Suse etc do not exist for Mageia.
Thanks

CC: (none) => sohel

@DavidG (mindful of your comment 3)
Is it easy to try the latest version (comment 7)?

If it is, and it works (does not fail to list partitions) - bingo.
If it is easy to try, but it still does not work - give up.
Also give up (wontfix) if it is not easy to try the latest version.

Why this application should be sacrificed (wontfix)? It is one of the most useful program to make images. Can you suggest a replacement as good? at the very least please provide a recipe to compile it as the components for the other distributions are not provided in the Mageia8 repositories.

(In reply to Lewis Smith from comment #10)
> @DavidG (mindful of your comment 3)
> Is it easy to try the latest version (comment 7)?
> 
> If it is, and it works (does not fail to list partitions) - bingo.
> If it is easy to try, but it still does not work - give up.
> Also give up (wontfix) if it is not easy to try the latest version.

Sohel, it is not my decision about whether this program should be retained or dropped from Mageia 8.
Given its very specific references to Suse & Fedora (RPMs), how it ever got into our repositories is curious.

As for alternatives - I now wonder whether this qt-fsarchiver is the only one with a proper GUI. I thought Clonezilla had one, but it looks like a curses interface; and Partclone is command line. As is Fsarchiver itself.

Ping daviddavid :
> Upstream https://github.com/DieterBaum/qt-fsarchiver is at Version-0.8.5-21
Can we update to that - if only to try it ?

*** Bug 30209 has been marked as a duplicate of this bug. ***

CC: (none) => herman.viaene

I built the actual qt-fsarchiver version 0.8.6-7 from upstream. I had to tweak the spec file a lot/little bit to get it compatible with the upstream version.

Findings:
- the message from bug 30209 that qt-fsarchiver-terminal is missing won't show up
- BUT: the main window still won't show any partitions

I did NOT rebuild fsarchiver. That means i used fsarchiver-0.8.5-2.mga8 together with my own qt-fsarchiver-0.8.6.7-1.mga8

Maybe the missing partitions could be related to our old fsarchiver package. I didn't try yet to build it.

Nope. I built fsarchiver 0.8.6 from upstream. The main window from qt-fsarchiver-0.8.6.7-1 still don't show the partitions.

Someone maybe try to build qt-fsarchiver-terminal as it should be required according https://sourceforge.net/p/qt-fsarchiver/code/ci/master/tree/

I tweaked our spec file for qt-fsarchiver a little bit more. The problem that no partitions show up in the window seems to be related to our own source files.

#Source1:            org.fsarchiver.qt5.policy
#Source2:            qt-fsarchiver.wrapper

After removing them (and roughly fiddling with the spec file), qt-fsarchiver-0.8.6.7-1.mga8 builds and the partitions show up properly in the main window.

Created attachment 13204 [details]
working (dirty) qt-fsarchiver.spec

Here my working (dirty) qt-fsarchiver.spec. Be aware that i didn't clean it up completely from debris of prior not working versions. I only commented them out.

Created attachment 13205 [details]
qt-fsarchiver-terminal.spec

Created attachment 13206 [details]
qt-fsarchiver.spec

Created attachment 13207 [details]
fsarchiver.spec

@Lewis
I checked the latest archives I made and it's loger ago than I thought to remember. From the dates (June-ish 2020) I guess these have been made by and for M7 installations, so I've never used it with M8.

loger=longer

Great thanks to sturmvogel for the large amount of work to fix this problem.
Over to DavidG to formalise it.
If & when it get to core/updates_testing, will the bug followers please test it.

CC: lewyssmith => (none)

qt-fsarchiver-0.8.6.7-1.1.mga8
qt-fsarchiver-terminal-0.8.6.7-1.1.mga8
sont maintenant dans les testing

CC: (none) => yves.brungard_mageia

# urpmi qt-fsarchiver
A requested package cannot be installed:
qt-fsarchiver-0.8.6.7-1.1.mga8.x86_64 (due to unsatisfied ccrypt)

CC: (none) => davidwhodgins

Hello,
I added ccrypt-1.11-1.mga8

This is a nasty program.

I ran qt-fsarchiver in konsole after using "su -" to become root.
Despite already being root, it asked for the sudo password. After
entering it plasma failed and I was logged out. The journal shows ...

Nov 08 10:24:34 sudo[82540]:     root : HOST=x3.hodgins.homeip.net ; TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/mkdir /temp1
Nov 08 10:24:34 sudo[82557]:     root : HOST=x3.hodgins.homeip.net ; TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/rmdir /temp1
Nov 08 10:24:39 kdeinit5[2440]: kdeinit5: Fatal IO error: client killed
Nov 08 10:24:39 kdeinit5[2440]: kdeinit5: sending SIGHUP to children.
Nov 08 10:24:39 kdeinit5[2440]: kdeinit5: sending SIGTERM to children.
Nov 08 10:24:39 kdeinit5[2440]: kdeinit5: Exit.
Nov 08 10:24:39 xdg-desktop-por[2914]: xdg-desktop-portal-gtk: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Nov 08 10:24:39 login[1822]: pam_unix(login:session): session closed for user dave
Nov 08 10:24:39 org.gtk.vfs.Daemon[2768]: A connection to the bus can't be made
Nov 08 10:24:39 kaccess[2599]: The X11 connection broke (error 1). Did the X11 server die?
Nov 08 10:24:39 kglobalaccel5[2514]: The X11 connection broke (error 1). Did the X11 server die?
Nov 08 10:24:39 kactivitymanagerd[2491]: The X11 connection broke (error 1). Did the X11 server die?
Nov 08 10:24:39 systemd[1]: getty@tty1.service: Succeeded.
Nov 08 10:24:39 polkit-kde-authentication-agent-1[2605]: The X11 connection broke (error 1). Did the X11 server die?
Nov 08 10:24:39 synergys[2743]: Synergy 1.13.0: [2022-11-08T10:24:39] FATAL: X display has unexpectedly disconnected
Nov 08 10:24:39 pulseaudio[2621]: X connection to :0 broken (explicit kill or server shutdown).
Nov 08 10:24:39 gmenudbusmenuproxy[2617]: The X11 connection broke (error 1). Did the X11 server die?
Nov 08 10:24:39 python3[2726]: The X11 connection broke (error 1). Did the X11 server die?
Nov 08 10:24:39 redshift-gtk[3096]: redshift-gtk: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Nov 08 10:24:39 org.kde.KScreen[2671]: ICE default IO error handler doing an exit(), pid = 2671, errno = 0
Nov 08 10:24:39 polkitd[2475]: Unregistered Authentication Agent for unix-session:1 (system bus name :1.34, object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_CA.UTF-8) (disconnected from bus)
Nov 08 10:24:39 kiod5[3051]: The X11 connection broke (error 1). Did the X11 server die?
Nov 08 10:24:39 systemd[1]: getty@tty1.service: Scheduled restart job, restart counter is at 1.
Nov 08 10:24:39 systemd[1]: Stopped Getty on tty1.

Besides crashing X, the problems I see, is that it should be using pkexec like
other programs. It should not be running /bin/rmdir /temp1. Who knows what the
user may already have in /temp1. It should be using a non-predictable temp
file or directory.

Keywords: (none) => feedback

Trying to run under MATE, but I don't get anywhere with this version.
When I start qt-fsarchiver as root, then it complains it cann't be run as root and closes.
When I start qt-fsarchiver as my normal user, it asks for a sudo password, but I never do, or have done, or will allow sudo passwords. So usabililty of this thing is zero.

It does have $ cat /usr/share/doc/qt-fsarchiver/README.urpmi
Important: This application needs that you have sudo configured for your user.

and from $ cat /usr/share/doc/qt-fsarchiver/Readme ...
For some distributions, the /etc/sudoers file must be completed with these lines:
username ALL=(ALL) ALL 
%sudo   ALL=(ALL:ALL) ALL
The username has to be adjusted: for example peter.

I'm more concerning with it killing X and everything else I had running,
returning me to the login prompt. I use run level 3 on this install, so
not only did it kill X, it killed getty, which systemd restarted.
It's also dangerous to use a fixed directory of /temp1 instead of generating
one using something like mktemp.

It has to be able to be run as root. After using "su -", programs such
as isodumper have no problem showing the gui. The only reason that it's
failing when using "su -" is that it has dangerous bugs.

Users running file system level utilities are going to expect to have to
run it as root.

Looking through the source, it's also using a temporary file in the
current directory called ".1", overwriting anything previously in that file.

This program should be removed from Mageia until it's file and password
handling can be fixed properly.

Added to bug 30163 to be obsoleted

Sysadmins, please remove qt-fsarchiver-0.8.6.7-1.1.mga8.src.rpm and
qt-fsarchiver-terminal-0.8.6.7-1.mga8.src.rpm from Mageia 8 core updates testing.
It's so badly written that it's dangerous for users that may try it.

Also please add qt-fsarchiver-0.8.5.18-3.mga8.src.rpm to task-obsolete for
Mageia 8.

(In reply to Herman Viaene from comment #28)
> When I start qt-fsarchiver as root, then it complains it cann't be run as
> root and closes.
> When I start qt-fsarchiver as my normal user, it asks for a sudo password,
> but I never do, or have done, or will allow sudo passwords. So usabililty of
> this thing is zero.
This is excessive. It is clearly usable with the caveats noted earlier, but not excusing them. Running as root seems to me more dangerous than sudo'ing.

(In reply to Aurelien Oudelet from comment #7)
> (In reply to David GEIGER from comment #3)
> > This package is completely broken due to an upstream source wrong structure.
> > For me this package should be removed from repo! I tried to fix it but
> > without real success.
> 
> We should remove this.

So we have been here before. Somebody noted somewhere that it was a nice package and worth having. But it looks beyond hope in its current state.
If it is ditched definitively, both this bug and bug 31071 should be closed 'wontfix' or 'invalid".

The gui handling is nice. The underlying working parts of the system will fail
in many cases where names contain spaces, due to the use of unquoted variables
and may lead to cases where untrusted input causes the root run script to
interpret a user's file names as commands.

It does not warn the user not to backup file systems that are in use.
Recovering from a backup made while the filesystem is in use will lead to
data loss, if not an un bootable system.

The package is fine for people who already know how to safely do backups and
have no untrusted users on their systems.

It is not safe for people who don't understand the dangers of using dd to
backup/restore a running system, or who have users who are not trusted to
have root access. It should not be packaged for Mageia.

The bug report should be closed after the package has been added to
task-obsolete in cauldron, and preferably Mageia 8 too.

(In reply to Lewis Smith from comment #32)
> This is excessive. It is clearly usable with the caveats noted earlier, but
> not excusing them. Running as root seems to me more dangerous than sudo'ing.

Just commenting on this part. The only difference between giving the user
sudo access to all commands and running as root is that with sudo, all
commands are logged. It isn't any safer.

The only reason the package will not allow itself to be run as root is that
the person who put that restriction in was using "su" instead of "su -" and
ran into problems handling .Xauthority

Hello,

This application worked fine on Mageia7 and earlier. Anybody compared what caused it to misbehave on Mageia8. If it can be restored to the same state despite all the safety considerations it is fine by me. If I had the software expertise I would have tried to fix it.  I am sorry to see applications broken as Mageia evolves. For now I am keeping a bootable version of Mageia7 from where I can use this program. 

In passing I do not see the big difference between su and sudo. Both when not used carefully can destroy the system. I never had any problem until now using either for the last 20 years. I was sorry to see applications like Dolphin where running it under su or sudo was removed.

(In reply to Dave Hodgins from comment #33)
> The gui handling is nice. The underlying working parts of the system will
> fail
> in many cases where names contain spaces, due to the use of unquoted
> variables
> and may lead to cases where untrusted input causes the root run script to
> interpret a user's file names as commands.
> 
> It does not warn the user not to backup file systems that are in use.
> Recovering from a backup made while the filesystem is in use will lead to
> data loss, if not an un bootable system.
This is the more important reasons to withdraw the program. Every week, we have alerts on some security flaws and we have to apply correction to avoid them. This kind of security alert is often what we see for this program.

Can anyone tell me why qt-fsarchiver worked fine in Mageia 7 (and earlier) and stopped working on Mageia 8? All the security issues can be addressed if one is willing. This is the reason why all the OS systems issue updates. I am sorry to see the easy way out is to withdraw the program without at least to replace it by an equivalent. By the way the bug report was created because the program failed and not because of a security problem.

It fails because it was never updated to work with newer versions of qt.

Here is the solution I found

Installation of qt-fsarchiver on Mageia8

Downloaded from Sourceforge: qt-fsarchiver released /rpm-packages/Suse/Suse-Leap-15-3,Leap-15-4/rpm/qt-fsarchiver-0.8.6_10-0.x86_64.rpm

First installation required ccrypt and failed. Program ccrypt was not available in the Mageia8 CCM repository so I downloaded and installed from https://ccrypt.sourceforge.net/ ccrypt-1.11-1.x86_64.rpm
The second qt-fsarchiver-0.8.6_10-0.x86_64.rpm installation was successful and the program started flawlessly after entering the sudo password.
I tested the program and I was able to produce the image file of one of my partitions.

I think it should be easy work to have this version of the program (qt-fsarchiver-0.8.6_10-0.x86_64.rpm) replace the flawed one in the Mageia8 repository

Thank you for all your work.

But does it resolve the issues recently found?
* Basic flaws in the program itself: comment 29, comment 33.
* Its behaviour when run as root: comment 28, comment 34.

I wonder whether the running as root business is that complicated. I have scripts which have to be run as root, which just check for UID 0, and give up if not. As far as I can tell, sudo gives that result. Could one not simply check for that, and if not, pop the current sudo password dialogue? And if you do not have sudo, you can just abandon.

I did some research. Initially I wanted to see if it could be run on Kubuntu. I eventually succeeded installing it on 22.04.with the *.deb installation file. I was only by accident I succeeded running it only once (still investigating). After that It rejected my sudo password pretending it is wrong. When I tried to running as root it complained that it must not be run as root. It wants to be run as simple user but needs a sudo password (or perhaps a root password (not available in Kubuntu)).

On Mageia8 once the installation done as described in comment 39 and run as user (not root) and once the sudo password entered everything was fine and the functionality available earlier were there plus more (compressing techniques). 

I think the version 0.8.6_10-0.x86_64 addresses most of the earlier issues but I am not a software specialist to confirm. To me as is, is all I want and need.

The issue of comment 28 is not addressed and the program requires a sudo or perhaps a root password. For me this is acceptable. For such users (that do not have a sudo password) I would recommand downloading the qt-fsarchiver iso file and burn it as live cd. No password is then required. A good tool to have if the system crashed.

From my point of view as installed on Mageia8 safety is ensured. The worse problem that may occur is if one attempts to retaure with the wrong image. But even then the  program gives a confirmation of what it about to do for one to check before committing.

For my own curiosity I would like to investigate why I have problems running it On Kubuntu 22.04. But this is not part of this bug investigating.

Finally perhaps someone else more knowledgeable can install and investigate it to cover all the concerns. But for me it is a wonderful tool I have been using for a long time and it would be a pity to discard it from Mageia.

I've read a suggestion (probably in the qa-discuss list) that giving the normal user the wheel group would impact the behavior.
I added the wheel group to the normal user, logged out and in again. The qt-fsarchiver now still asks the sudo password, but when I enter the users password, qt-fsarchiver proceeds further displaying the partitions and backups.
So, as far as I am concerned, I would hate to see this package disappear from Mageia. I wonder what the best way would be to assure that other people (or myself in the future) are made aware of this solution.
I have no further objection to OK this update.

What is the status in Mageia 9?

Applying the same trick as explained above Comment 42, it is writing a backup right now.

(In reply to Morgan Leijström from comment #43)
> What is the status in Mageia 9?

Due to the changes in default settings for ext4 partitions, slightly worse
than in m8.

/usr/sbin/qt-fsarchiver.sh: line 74: cd: /home/dave/.qt-fs-client: No such file or directory
src/fs_ext2.c#525,extfs_getinfo(): this filesystem has ext{2,3,4} features which are not supported by this fsarchiver version.
src/oper_save.c#1152,filesystem_mount_partition(): cannot save filesystem attributes for partition /dev/sda1

Trying the M8 version comments 24/26 in Updates/Testing:
  ccrypt                         1.11         1.mga8        x86_64  
  qt-fsarchiver                  0.8.6.7      1.1.mga8      x86_64  
  qt-fsarchiver-terminal         0.8.6.7      1.mga8        x86_64  

It has cured the old faults noted in comment2 (+ the empty partition pane), and behaves just like the Cauldron version:
- no menu entry
- just the mysterious 'sudo' password requested (comment 42)
- correctly shows disc partitions
- presumably the problem with newer (M9) ext4 partitions
Comment 42 & comment 44 are potent recommendations for it, whatever its other faults. It clearly has a strong user demand.

Keywords: feedback => FOR_ERRATA8

OK so shipping the updates now in testing is the best we can do, accompanied with an entry in errata 8.

I suggest we also ship it in mga9, with an errata entry there too.

In both cases prominently including note on ext4 and explanation - as well as need for sudo and start manually.  Also note this will not be solved, and they should look for switching to other software.

This is best effort - regarding a popular program.

See it as a service -  
* specifically as many users have made backups they may need to read some day. *

Whiteboard: (none) => MGA8TOO, MGA8-64-OK
Version: 8 => Cauldron
Keywords: (none) => FOR_ERRATA9, validated_update

Just a reminder concerning Comment 46. Please refer to my Comment 39. 

I had installed "qt-fsarchiver-0.8.6_10-0.x86_64.rpm" obtained from Sourceforge. It played and behaved on M8 exactly as the version offered by the M7 MCC on M7. It helped me make images of my Ext4 partitions without problem. 

I believe it should not be so difficult to simply have the M8 MCC offer it on M8 instead of the flawed one... et le tour est joué!

Can someone explain (or give a link to) this business of errata 8 and ext4 partition problem? Thanks.

Interesting, Sohel!

Anyway, for now in: https://wiki.mageia.org/en/Mageia_8_Errata#Various_software

Status comment: (none) => Update Errata 8 when out of testing
Keywords: FOR_ERRATA8 => IN_ERRATA8

(In reply to Sohel Fares from comment #48) Also comment 39

> Just a reminder concerning Comment 46. Please refer to my Comment 39. 
> I had installed "qt-fsarchiver-0.8.6_10-0.x86_64.rpm" obtained from
> Sourceforge. It played and behaved on M8 exactly as the version offered by
> the M7 MCC on M7. It helped me make images of my Ext4 partitions without
> problem. 
Can you say how the version you downloaded [version 0.8.6_10-0.x86_64] differs from - particularly, how it is better than - the new Mageia 8 qt-fsarchiver as noted in comment 46?
* Does it have a menu entry?
* What password does it ask for?
* Do you *know* that it will handle enhanced Mageia 9 ext4 partitions?

I suspect what we have now is as good as what you downloaded.

@ DavidG
"I think it should be easy work to have this version of the program (qt-fsarchiver-0.8.6_10-0.x86_64.rpm) replace the flawed one in the Mageia8 repository" 
"I had installed "qt-fsarchiver-0.8.6_10-0.x86_64.rpm" obtained from Sourceforge. It played and behaved on M8 exactly as the version offered by the M7 MCC on M7.
I believe it should not be so difficult to simply have the M8 MCC offer it on M8 instead of the flawed one"
I that 'flawed' is now unjustified for Mageia.
BTAIM Is this suggestion a possibility - if it proved justified?

@Morgan
I second your comment 47. Thanks for that résumé.

Hello Lewis and DavidG

A few answers:
*Can you say how the version you downloaded [version 0.8.6_10-0.x86_64] differs from - particularly, how it is better than - the new Mageia 8 qt-fsarchiver as noted in comment 46?
A couple of months or so ago I had to re-install Mageia 8 from scratch on another computer. So I went to the M8 MCC and installed the qt-fsarchiver it offered. This one had the partition pane empty so I uninstalled it and installed the one described in Comment 39. This one worked perfectly. Unfortunately I did not recall which version the MCC one was. So my answer is I do not know for sure.(Going back to the one in the M8 repository in the MCC is impossible. Now only qt-fsarchiver-0.8.6_10-0.x86_64 is displayed). Another observation: to install the latter I uninstalled both fsarchiver and qt-fsarchiver then I only installed qt-fsarchiver-0.8.6_10-0.x86_64.rpm.


* Does it have a menu entry?
Here is how it looks 
https://u.pcloud.link/publink/show?code=XZU4hOVZNXW18mtw1OQSBIUCOYvWOBLnODty* 

*What password does it ask for?
It asks for the sudo password to start. Note that my sudo password is the same as my root password.

* Do you *know* that it will handle enhanced Mageia 9 ext4 partitions?. 
No I do not. Are the ext4 partitions different on M9? It saved my ext4 partitions on M8.

DavidG
*I that 'flawed' is now unjustified for Mageia.
The one I got from the M8 MCC two months ago did not work (see my answer above)

(In reply to Sohel Fares from comment #51)
> * Does it have a menu entry?
> Here is how it looks 
> https://u.pcloud.link/publink/
> show?code=XZU4hOVZNXW18mtw1OQSBIUCOYvWOBLnODty* 
This does not answer the question. It shows the running GUI, not the application menu.
The picture is too poor to assess. Why not attach a straight screenshot?
One can discern that there are slight differences from our new qt-fsarchiver, but whether these matter cannot be judged from your example image.
 
> *What password does it ask for?
> It asks for the sudo password to start
Same for both.

> * Do you *know* that it will handle enhanced Mageia 9 ext4 partitions?. 
> No I do not. Are the ext4 partitions different on M9? It saved my ext4
> partitions on M8.
See comment 45. You will not be there yet.

> *[..] 'flawed' is now unjustified for Mageia.
> The one I got from the M8 MCC two months ago did not work
True. We all agreed about that! Whence this bug, now essentially resolved for Mageia 8. Please accept that your original complaints (substantiated by others) are cured by: qt-fsarchiver 0.8.6.7 1.1.mga8 x86_64
rather than continuing to complain that what Mageia offers is useless? It was, but thanks to a lot of work, no longer is.
TIA

Does anyone object to closing this fixed (with ERRATA explanations)?

IMO close as fixed

We need to work on short yet enough complete explanations for both errata 8 & 9.

Do the sudo problem show for also running fsarchiver directly, or only with qt-fsarchiver?

It should work to restore an old backup of a non C12 ext4 filesystem to a partition, right? - regardless of running on Mageia 8 or 9, because "FSArchiver also creates the file-system when it extracts the data to partitions." https://www.fsarchiver.org/  Correct?

Running fsarchiver directly never was a problem for me, qt-fsarchiver is the PITA.

Closing as the revised program adresses the original bugged complaints.

Resolution: (none) => FIXED
Status: NEW => RESOLVED

Reopening. It won't be fixed until an advisory is committed to svn and the
update pushed from updates testing to updates.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Advisory committed to svn as
type: bugfix
subject: Updated qt-fsarchiver packages fix bugs
src:
  8:
   core:
     - qt-fsarchiver-0.8.6.7-1.1.mga8
     - ccrypt-1.11-1.mga8
description: |
  Fix running of qt-fsarchiver and adds ccrypt package.
references:
 - https://bugs.mageia.org/show_bug.cgi?id=28791

Keywords: (none) => advisory

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2023-0049.html

Resolution: (none) => FIXED
Status: REOPENED => RESOLVED

Updated Errata 8

Entered in Errata 9: https://wiki.mageia.org/en/Mageia_9_Errata#Various_software

Question unanswered in comment 53:
Can a Mageia user restore an archive to a new partition?
Does it fail if there are already a filesystem there, but it works for an unformatted partition, or if it overwrite?

Keywords: FOR_ERRATA9 => IN_ERRATA9
Status comment: Update Errata 8 when out of testing => (none)

To a new partition I don't know. What I did was save a partition  (sda7) with an M8 installation, installed (new install) an M9 on this partition ,(that includes a formatting during the installation), save this partition an restore the saved M8. Worked OK.

The current m9 version can read an m8 generated archive. It displays ...

The partition to be recovered  /dev/sdb1 m9data does not coincide with the saved  /dev/sda3 Do you still want to perform the recovery?

If yes is selected it reformats the partition using the options that m8 uses.

So m9 fsarchiver can restore an m8 generated archive, it just can not read
an ext4 partition formatted in m9 using the m9 options.

Thanks guys :)
Perfect.
Updated https://wiki.mageia.org/en/Mageia_9_Errata#Various_software