Help! I somehow deleted Windows files that I need

[Rapha_]

I can't get testdisk to copy the selected files to the USB drive's /mnt/sda6 drive. All the listed folders are Porteus live folders.

I'm testing TestDisk now...You are using [advanced > undelete] ?

Selecting a disk or folder is not enough, you have to go into it with [Enter] to work...

[Ed_P]

You are using [advanced > undelete] ?

Yes. And to copy the files to another drive I found requires testdisk to be started in the other drive.

[Rapha_]

From what I've seen, it suggests /home/guest/ as the default destination,
but you can change disk and folder by modifying: using the arrows and ".." "." to return to the root folders.
and after "/mnt/" to choose another disk.

Were you able to copy as much data as possible intact?

[Rava]

From what I've seen, it suggests /home/guest/ as the default destination,

You must start testdisk as root. But even then, usually /root/ is similar limited on most systems as /home/guest/ is limited. Which system admin would give /root/ 520 GB of free space by default, and you need approx that to safely start a rescue operation of a 500 GB lost partition. That would hardly work in any sane environment. And in our case, saving restored files onto the RAM disk borders with insanity.

But seems Ed_P looked into the technical details good enough to be on the right path.

you can change disk and folder by modifying: using the arrows and ".." "." to return to the root folders.
and after "/mnt/" to choose another disk.

Back in 2020 I used the outdated testdisk 7.2 WIP and I do not recall how I had to do it. I do not recall having to start testdisk from the target partition, but maybe I did. In cases like these I usually read into the finer workings beforehand while experimenting with the software but not yet starting the real operation, to get a better grasp how it works and about possible pitfalls, and when all looks like described on the support forum or in readme's or in a wiki article, then I finally start the operation for real.

Added in 1 minute 31 seconds:
And I usually rely on not just one of from readme, howto, wiki, in such case I want at least the confirmation of at least two of these information sources.

[Ed_P]

So to make my testdisk easier to use I created a bash script, part of which is shown in the image's top left corner. Nothing fancy. But when I execute it I get an error stating the xzm module is invalid, shown in the bottom left corner. If I manually execute the activate command in a terminal window,shown in the image in the middle at the bottom, I get the same error! If I go to the folder on the drive, shown in the image in the middle at the top, and click on testdisk it activates, seen in the image at the top right. And starting it in a terminal window works like before.

[Rava]

Could it be your script

to make my testdisk easier to use I created a bash script, part of which is shown in the image's top left corner. Nothing fancy. But when I execute it I get an error stating the xzm module is invalid

has some tiny error in it you overlooked?
When all works as intended when doing the activation of the testdisk module manually, then the only reasonable culprit remains the script.

Have a mini fan fiction on that:

Holmes: Therefore, I deduce your simple script must be the reasonable culprit for the misbehaviour you witnessed.
Watson: … … …
Holmes: Elementary, my dear Watson.
Watson: At least in theory, my dear Holmes. At least in theory…
Holmes: …

Added in 10 minutes 2 seconds:
Aside from making fun of the tropes that are Watson and Holmes…

If I go to the folder on the drive, shown in the image in the middle at the top, and click on testdisk it activates, seen in the image at the top right. And starting it in a terminal window works like before.

Kinda weird indeed.
Are you running Porteus 5.0 or 5.0.1?

Added in 5 minutes 8 seconds:
For now try the following: make a copy of your testdisk module, in the same folder, and simply call it testdisk.xzm
Try the above again.

And if that also fails, move your copied "testdisk.xzm" (keep your originally named more verbose version of your testdisk module untouched and as it is) into /mnt/sdb1/ and into /mnt/sda6/ and try both these variants to see if any of these work.

[Ed_P]

My prior image showed events from 2 different drives, my harddrive and my USB drive. This one is consistent with all events done on the USB drive. Same results.

Added in 20 minutes 34 seconds:
If I change the script's if statement, like so:

Code: Select all

if [ ! -e /mnt/live/memory/images/gpart*.xzm ]; then 
   activate $OPTIONAL/$TESTDISK   > /dev/null 2>&1 &
   activate $OPTIONAL/gpart*.xzm  > /dev/null 2>&1 &
fi

I don't get the error message. But testdisk doesn't get activated either.

[Rava]

If I change the script's if statement, like so:

Code: Select all

if [ ! -e /mnt/live/memory/images/gpart*.xzm ]; then 
   activate $OPTIONAL/$TESTDISK   > /dev/null 2>&1 &
   activate $OPTIONAL/gpart*.xzm  > /dev/null 2>&1 &
fi

I don't get the error message. But testdisk doesn't get activated either.

Leave out the > /dev/null 2>&1 part and see if it hides some crucial information.
You should only add > /dev/null 2>&1 when the script works as intended, e.g. after testing it and when all seems okay.

Later on when encountering any issues leave out all and any > /dev/null 2>&1 until all debugging solved all issues.

[Ed_P]

Actually I did but the results weren't helpful so I didn't post the results.

Some how bash's activate is different then the activate when clicking on the module in the file manager. A 5.0.1 issue?

Code: Select all

~#  uname -a
Linux porteus.example.net 6.5.5-porteus #1 SMP PREEMPT_DYNAMIC Sat Sep 23 18:21:43 MSK 2023 x86_64 Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz GenuineIntel GNU/Linux

~#  cat /etc/porteus/*
001-core.xzm:20230922
002-xorg.xzm:20231001
002-xtra.xzm:20230922
003-cinnamon.xzm:20230922
initrd.xz:20230923

[Rava]

Some how bash's activate is different then the activate when clicking on the module in the file manager. A 5.0.1 issue?

Not for me. I have several scripts in /usr/local/bin/ for activating rarely used modules. And for deactivating them, cause activate works that way when you start it on an already activated module.

The only addition is my script checks if the module file(s) exist and print the file(s) sizes.
And if needed my scripts also create symlink(s) for libraries if the program insists on finding an older version of that lib (that requirement is met by the existing newer version of the lib, so a mere symlink will do)

These are currently all of my activate-* scripts:

Code: Select all

activate-011-slapt-get            activate-leafpad
activate-abcde                    activate-libjpeg+libpng
activate-aria2                    activate-libjpeg+libtiff+libjbig
activate-audacious                activate-libreoffice
activate-audacity                 activate-moc
activate-btop                     activate-netsurf
activate-chromium                 activate-onlyoffice
activate-fbreader-0.12            activate-palemoon
activate-firefox                  activate-recordmydesktop
activate-gimp                     activate-redshiftgui
activate-gimp-2.10.22             activate-rendera
activate-gimp-2.10.8              activate-rkhunter
activate-gimp-2.8.6               activate-shellcheck
activate-graphicsmagick           activate-signal
activate-hardinfo                 activate-slapt-get
activate-interlink                activate-xmahjongg

(Not all of these work in my current system, e.g. activate-gimp-2.8.6 would need more dependencies, I am just too lazy to change that for now)

And when the parameter -i aka --info was given - this is currently the only valid option for all of these scripts - the scripts show only the info about module to be loaded when starting this script without any parameter. In other words, the module will not be activated but only shown if the module exists where the script was coded to find it and what size the module(s) have, e.g.:

Code: Select all

root@rava:~# activate-hardinfo -i
activate-hardinfo V0.3
 233472 2012-07-08 17:15 /mnt/sda5/Porteus_modules/5.0/hardinfo-0.5.1-x86_64-1pw.xzm
1	/mnt/sda5/Porteus_modules/5.0/hardinfo-0.5.1-x86_64-1pw.xzm

thus I can check which module it would load, and e.g. edit the activate-* script to change to a newer version (in recent days: in case of browser updates due to some recent CVE vulnerabilities.)

And all scripts can only be executed by root:

Code: Select all

root@rava:/usr/local/bin# ls -o activate-hardinfo 
-rwxr--r-- 1 root 1635 2021-09-28 22:03 activate-hardinfo

and guest or any non-root user gets this:

Code: Select all

guest@rava:~$  activate-hardinfo
bash: /usr/local/bin/activate-hardinfo: Permission denied

The code for activating is as simple as can be:

Code: Select all

root@rava:/usr/local/bin# grep "activate " activate-hardinfo
		    echo activate "$actifile"
		    activate "$actifile"

I just put the name of the module into a variable for making it easier to change (when I switch to a newer version of the module, or when I want to create a new activate-whatever script using an existing one as template [I am lazy as that. Scripting is meant to make your life easier, not harder. Work smarter, not harder])

And it all works in 5.0.1 as should be:

Code: Select all

root@rava:~# cat /etc/porteus/*
001-core.xzm:20230922
002-xorg.xzm:20230922
002-xtra.xzm:20230922
003-xfce.xzm:20230922
06-man.xzm:20230915
initrd.xz:20220928
root@rava:~# ls -ld /mnt/live/memory/images/hardinfo-0.5.1-x86_64-1pw.xzm
/bin/ls: cannot access '/mnt/live/memory/images/hardinfo-0.5.1-x86_64-1pw.xzm': No such file or directory
root@rava:~# activate-hardinfo 
activate-hardinfo V0.3
activate /mnt/sda5/Porteus_modules/5.0/hardinfo-0.5.1-x86_64-1pw.xzm
Updating shared library links:  /sbin/ldconfig
'libgnutls.so.26' -> 'libgnutls.so.30'
'./libc.so.6' -> '/lib64/libc.so.6'
root@rava:~# ls -ld /mnt/live/memory/images/hardinfo-0.5.1-x86_64-1pw.xzm
drwxr-xr-x 4 root root 37 2012-01-10 13:56 /mnt/live/memory/images/hardinfo-0.5.1-x86_64-1pw.xzm
root@rava:~# hardinfo --version
HardInfo version 0.5.1
Copyright (C) 2003-2009 Leandro A. F. Pereira. See COPYING for details.

Compile-time options:
  Release version:   Yes (ARCH_x86_64)
  BinReloc enabled:  Yes
  Data prefix:       /usr/share/hardinfo/
  Library prefix:    /usr/lib/hardinfo/
  Compiled on:       Linux 2.6.35.10 (darkstar)
Modules:
File Name           Name           Version     
computer.so         Computer       0.5.1       
devices.so          Devices        0.5.1       
network.so          Network        0.5.1       
benchmark.so        Benchmarks     0.5.1       
root@rava:~# 

As you can see, previously hardinfo-0.5.1-x86_64-1pw.xzm was not activated / not to be found in /mnt/live/memory/images/.

I activated it via activate-hardinfo V0.3 that also creates two needed symlinks to libraries.

Now ls shows the module is to be found in /mnt/live/memory/images/.

And last but not least, starting the program shows it all works.

Just as planned.

Added in 23 minutes 45 seconds:
OffTopc since it is not about generic script for activating modules anymore.
And I realized the outdated hardinfo v0.5.1 has some minor issues.
It gave the error during execution of creating a report

Code: Select all

sh: -c: option requires an argument

Dunno what's the consequence of that error.

And in the report there is stuff like this:

Code: Select all

Display
Resolution	0x0 pixels

Such resolution would hardly be practical.

[Ed_P]

And it all works in 5.0.1 as should be:

Code: Select all

root@rava:~# cat /etc/porteus/*
001-core.xzm:20230922
002-xorg.xzm:20230922      <------------------- 5.0
002-xtra.xzm:20230922
003-xfce.xzm:20230922
06-man.xzm:20230915
initrd.xz:20220928

This is what my 5.0.1 cat /etc/porteus/ shows:

Code: Select all

001-core.xzm:20230922
002-xorg.xzm:20231001        <------------------- 5.0.1 
002-xtra.xzm:20230922
003-cinnamon.xzm:20230922
initrd.xz:20230923

And I have other scripts that activate Optional modules that's why this problem is so strange.

Code: Select all

echo toor | sudo -S activate $OPTIONAL/$SOLITAIRE > /dev/null 2>&1 &

echo toor | sudo -S activate /mnt/$DRV/porteus5.0/Optional/tightvnc-*.xzm  > /dev/null 2>&1 &

if [ ! -e /mnt/live/memory/images/$MODULE ]; then
   echo $PSWD | sudo -S activate $OPTIONAL/$MODULE > /dev/null 2>&1 &
   sleep 2
   sudo -S sed -i 's^=gksu ^=psu ^' /usr/share/applications/gslapt.desktop
   sudo -S sed -i 's^;System;^;System;Filesystem;^' /usr/share/applications/gslapt.desktop
   sudo -S /usr/sbin/gslapt
fi

[Rava]

And it all works in 5.0.1 as should be:

Code: Select all

002-xorg.xzm:20230922      <------------------- 5.0

This is what my 5.0.1 cat /etc/porteus/ shows:

Code: Select all

002-xorg.xzm:20231001        <------------------- 5.0.1 

002-xorg.xzm:20230922 is from the 5.0.1 ISO. (You see that the other base module have the same date) Seems there is already an update for 5.0.1.

I will check it out.

Added in 2 minutes 53 seconds:
Indeed
http://www.mirrorservice.org/sites/dl.p ... 2-xorg.xzm
I missed that update.
Is there a readme describing what this update in 002-xorg.xzm is about?

Added in 3 minutes 30 seconds:
Currently downloading, after a reboot I will test if the same activate-hardinfo works as it did with the original 002-xorg.xzm:20230922 module and report back in here.

Added in 8 minutes 39 seconds:
Now I have this:

Code: Select all

guest@rava:~$ cat /etc/porteus/*
001-core.xzm:20230922
002-xorg.xzm:20231001
002-xtra.xzm:20230922
003-xfce.xzm:20230922
06-man.xzm:20230915
initrd.xz:20220928

and my activate-hardinfo works as reliable as it did before.

[Ed_P]

Is there a readme describing what this update in 002-xorg.xzm is about?

Porteus-v5.01 is released!

Now I have this:

Code: Select all

guest@rava:~$ cat /etc/porteus/*
001-core.xzm:20230922
002-xorg.xzm:20231001
002-xtra.xzm:20230922
003-xfce.xzm:20230922
06-man.xzm:20230915
initrd.xz:20220928

Added in 4 minutes 16 seconds:
Why are we referring to the current release as 5.0.1 when the official announcement is titled 5.01?

[Rava]

Why are we referring to the current release as 5.0.1 when the official announcement is titled 5.01?

Good question, I dunno.

Porteus-v5.01 is released!

That refers to all of 5.01 /5.0.1 - when i was asking specifically about the difference between
002-xorg.xzm:20230922
and
002-xorg.xzm:20231001

And BTW, you have been mistaken in believing my older 002-xorg.xzm:20230922 is 5.0 - like I said, it is the original non-updated 002-xorg.xzm as in the ISOs.

[Ed_P]

Narrowing down the problem.
This:

Code: Select all

#!/bin/sh

OPTIONAL="/mnt/sda6/porteus5.0/Optional"       # harddrive
#OPTIONAL="/mnt/sdb1/Optional"                  # USB drive
TESTDISK="testdisk-7.2-WIP-x86_64-Aug2023.xzm" # version
TESTDISK="testdisk-7.2-WIP-x86_64-rava.xzm"
#awk 'c-->0;/Booting device:/{c=1}' /var/log/porteus-livedbg

if [ `whoami` != "root" ]; then
   echo -e "Enter root's password\033[1;31m"
   su -c "sh $0 $1 $2"; exit
fi
echo -e "\033[0m"; echo -en "\033]0;testdisk\a"

set -x;

if [ ! -e /mnt/live/memory/images/gpart*.xzm ]; then 
   activate $OPTIONAL/gpart*.xzm  # > /dev/null 2>&1 &
fi
if [ ! -e /mnt/live/memory/images/$TESTDISK ]; then 
   activate $OPTIONAL/$TESTDISK   # > /dev/null 2>&1 &
fi

read -p "Enter backup drive.  ( /mnt/sd__ /dev/sd__ ) " BKDRV

if [ ! $BKDRV == "" ]; then
   cd $BKDRV
   echo && echo == $BKDRV ==
   ls -lght
   read
   mkdir -p Recovery
fi

testdisk

exit

does this:

Code: Select all

Enter root's password
Password: 

+ '[' '!' -e '/mnt/live/memory/images/gpart*.xzm' ']'
+ activate /mnt/sda6/porteus5.0/Optional/gpart-0.3-x86_64-2salix15.0.xzm
Updating shared library links:  /sbin/ldconfig
+ '[' '!' -e /mnt/live/memory/images/testdisk-7.2-WIP-x86_64-rava.xzm ']'
+ activate /mnt/sda6/porteus5.0/Optional/testdisk-7.2-WIP-x86_64-rava.xzm
Updating shared library links:  /sbin/ldconfig
+ read -p 'Enter backup drive.  ( /mnt/sd__ /dev/sd__ ) ' BKDRV
Enter backup drive.  ( /mnt/sd__ /dev/sd__ ) 

which IMO means this did something wrong.

But the module works when run manually.