Dear All, Every few years or so (I have only a few machines to maintain), I have occasion to use ddrescue, Today I see something that I cannot explain from the docu. Do you have any advice? I numbered parts of my text for easier reference. Thank you, Jan
Problem title: no status screen, no mapfile, no logfile Brief description: (details below): ddrescue <some other options --log-events=<file> <input partition> <outputfile> <mapfile> (1) does not produce any output to screen (no "Gnu ddrescue 1.23 \nPress Ctrl-C to interrupt", no progress display with bytes read/written etc.). Nothing. (2) Moreover, there is no trace of the mapfile or the logfile (in the current working directory) and "lsof ddresc" shows (besides some glibc files) only the <input partition> and <outputfile> as open files for ddrescue (and file descriptors 0, 1, 2 to /dev/tty1, which is the termninal where I am logged in.) (3) The <outputfile> is slowly growing (now about 300GB, after 16 hours, i.e. 7MB/s), but without mapfile it is not possible to have a next run for scraping. And I have no information how many bad sectors were encountered. (4) I am running as root under the systemd-"sulogin" rescue shell. When I am experimenting with the same command (other, smaller <inputfile> and <outputfile>) on another (healthy ) machine, everything works as expected. But that is a machine in multiuser state (run level 5), with a desktop pts-terminal, not a /dev/tty, even though that should not matter (?) Details: (5) version: ddrescue v1.23 on ubuntu linux 20.04.6 (6) full cmd line, the below script is invoked from bash shell: #!/usr/bin/bash fn=m16homecopy1 echo ddrescue --idirect --no-scrape --retry=passes=0 --preallocate --synchronous \ --log-events=$fn.log \ /dev/sdb1 /media/ikke/EB1/$fn.bin $fn.map #end of script (7) the input is the /home partition, which has its own disk; the output is to a file on an USB 3.0 HDD, which flashes its LED a few times /sec. (8) considerations: the --preallocate was applied to verify whether the "huge file" extended file attribute of the ext2 file system of <outputfile> disk was working I checked with ps -f that the script was expanded as I had intended. I did not use absolute paths for mapfile and logfile, but the process has a "normal" current working directiry. (9) I am not inclined to disconnect the "whacky drive" and bring it to another computer. I can restart, using a live USB linux distro, if the sulogin-shell is the problem, but first I would like to know whatÅ› wrong.