Re: [darktable-user] Ubuntu 22.04.1 and OpenCL

[Mikael Ståldal]

That's good advice.

However, in this case it was enough to just install the missing library, 
I did not have to recompile.



On 2022-08-18 05:52, Top Rock Photography wrote:

Mikael,

I am one who always compiles darktable myself. I usually watch the 
output during cmake. It often says things such as,


/Looking for libopencl-clang ≥ 12/

/Suitable version not found/

/Found libopencl-clang version 11.1.23. Requires version ≥ 12./

/Darktable will be built without optional OpenCL support./

…or something to that effect.

The /cmake/ will complete, the /make/ will complete, the /sudo make 
install/ will complete.


When I find these warnings in the cmake phase, I immediately stop the 
compile, install the missing libraries/dependencies, clean the [build] 
directory, and start over.


I find every now and then, when a new version of darktable comes out, 
they are built against newer libraries, probably for improved 
optimisations or to avoid bugs in older libraries. This behaviour is normal.


Ubuntu will often upgrade certain toolboxes to the latest iteration of 
the version you have, but not to a new version, since it may break other 
projects on which you are currently working. For example, it may update 
Python3 from version 3.10.4 to version 3.10.6, or even to version 
3.12.0, but if Python4 comes out, it will still only update you to 
Python 3.12.2, and not Python4 version 4.0.2. This is because you may 
still have applications dependent on Py3, and that Py4 may be incompatible.


Sometimes one can install multiple versions of a toolbox, and 
specifically invoke the version you want.


/python3 foo.py/

/python4 bar.py/


Anyways, now you know for future reference. Hope I was helpful.

Sincerely,

Karim Hosein
Top Rock Photography
754.999.1652



On Wed, 17 Aug 2022 at 13:12, Mikael Ståldal > wrote:


I did not have that, installing libopencl-clang13 solved my problem,
thanks!

Is this documented somewhere?




 
darktable user mailing list to unsubscribe send a mail to 
darktable-user+unsubscr...@lists.darktable.org


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Ubuntu 22.04.1 and OpenCL

[Top Rock Photography]

Mikael,

I am one who always compiles darktable myself. I usually watch the output
during cmake. It often says things such as,

*Looking for libopencl-clang ≥ 12*

*Suitable version not found*

*Found libopencl-clang version 11.1.23. Requires version ≥ 12.*

*Darktable will be built without optional OpenCL support.*

…or something to that effect.

The *cmake* will complete, the *make* will complete, the *sudo make install*
will complete.

When I find these warnings in the cmake phase, I immediately stop the
compile, install the missing libraries/dependencies, clean the [build]
directory, and start over.

I find every now and then, when a new version of darktable comes out, they
are built against newer libraries, probably for improved optimisations or
to avoid bugs in older libraries. This behaviour is normal.

Ubuntu will often upgrade certain toolboxes to the latest iteration of the
version you have, but not to a new version, since it may break other
projects on which you are currently working. For example, it may update
Python3 from version 3.10.4 to version 3.10.6, or even to version 3.12.0,
but if Python4 comes out, it will still only update you to Python 3.12.2,
and not Python4 version 4.0.2. This is because you may still have
applications dependent on Py3, and that Py4 may be incompatible.

Sometimes one can install multiple versions of a toolbox, and specifically
invoke the version you want.

*python3 foo.py*

*python4 bar.py*


Anyways, now you know for future reference. Hope I was helpful.

Sincerely,

Karim Hosein
Top Rock Photography
754.999.1652



On Wed, 17 Aug 2022 at 13:12, Mikael Ståldal  wrote:

> I did not have that, installing libopencl-clang13 solved my problem,
> thanks!
>
> Is this documented somewhere?
>
>
>
>


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Ubuntu 22.04.1 and OpenCL

[Mikael Ståldal]

I did not have that, installing libopencl-clang13 solved my problem, thanks!

Is this documented somewhere?


On 2022-08-17 18:10, Šarūnas wrote:

On 8/17/22 04:17, Mikael Ståldal wrote:
I have all of those (except nvidia-modprobe), and I have 
/usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1


Do you also have either ocl-icd-libopencl1 or cuda, which provide 
libOpenCL.so?


ldconfig -v |grep -i opencl


On 2022-08-16 22:48, Šarūnas wrote:

On 16/08/2022 15.51, Mikael Ståldal wrote:
So which OpenCL library do I need? I tried to install 
libopencl-clang-dev, but it does not help.


On 22.04.1 with RTX 2070, where OpenCL works, there are following 
installed:


$ dpkg -l \*nvidia\*|grep ^ii
ii libnvidia-cfg1-515:amd64
ii libnvidia-common-515
ii libnvidia-compute-515:amd64
ii libnvidia-decode-515:amd64
ii libnvidia-egl-wayland1:amd64
ii libnvidia-encode-515:amd64
ii libnvidia-extra-515:amd64
ii libnvidia-fbc1-515:amd64
ii libnvidia-gl-515:amd64
ii nvidia-compute-utils-515
ii nvidia-dkms-515
ii nvidia-driver-515
ii nvidia-kernel-common-515
ii nvidia-kernel-source-515
ii nvidia-modprobe
ii nvidia-prime
ii nvidia-settings
ii nvidia-utils-515
ii xserver-xorg-video-nvidia-515

/usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 is part of
libnvidia-compute-515 package.




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] dt 4.0 corrupts disk

[Patrick Shanahan]

* Jean-Luc  [08-17-22 12:46]:
> Le 17/08/2022 à 15:33, Remco Viëtor a écrit :
> > On mercredi 17 août 2022 15:12:35 CEST Jean-Luc wrote:
> > > Le 17/08/2022 à 13:45, Patrick Shanahan a écrit :
> > > > * Jean-Luc  [08-17-22 06:12]:
> > > > > Le 16/08/2022 à 23:17, I. Ivanov a écrit :
> > > > > > On 8/16/22 13:59, Patrick Shanahan wrote:
> > > > > > > * Jean-Luc  [08-16-22 16:42]:
> > > > > > > I would definitely try another external drive and maybe try to 
> > > > > > > store
> > > > > > > on a
> > > > > > > local drive and move the files after finishing.
> > > > > > Agree with Patrick.
> > > > > > 
> > > > > > It is more likely the DD responds with corrupting the data because 
> > > > > > of
> > > > > > the operation (writing xml I expect) than Darktable actually doing
> > > > > > something wrong.
> > > > > > 
> > > > > > If it is a spin disk – you may want to check it for bad sectors. But
> > > > > > what Patrick suggest should take the disk out of the equation
> > > > > > completely.
> > > > > > 
> > > > > > Regards,
> > > > > > 
> > > > > > B
> > > > > Hello,
> > > > > 
> > > > > First, it is Testdisk, not memtest - I do not know why I always 
> > > > > mention
> > > > > the
> > > > > second instead of the first... 😬
> > > > > And I do not know as well why I wrote the scan lasts two hours, since 
> > > > > it
> > > > > takes more than twelve. 😬😬
> > > > > And, yes, does not really reflect the reality : as I have still not
> > > > > upgraded to 22.04, the problem might be caused by anything else than 
> > > > > dt
> > > > > itself, so a log would have been a good starting point.
> > > > > My interrogation was whether dt coul have saved a crash dump though
> > > > > launched as usual - ie with no commuter, aso. The answear is obviously
> > > > > no,
> > > > > unfortunately.
> > > > > The last time it happened I ran a full test after restoration (another
> > > > > 12+
> > > > > hours) and no bad sector was detected.
> > > > > In any case, I have a backup of the files, I just need to get the
> > > > > sidecars
> > > > > then I can copy to another disk and restart clean.
> > > > you are still not eliminating possibilities with your current approach.
> > > Yes, I do, since I intend to copy the files to another disk. I just need
> > > to retrieve my sidecars first.
> > > 
> > > > try first to export to a local disk.
> > > That might not be really relevant, the problem does not occur
> > > systematically. Only two times since dt upgrade and heavy work
> > > (reworking my whole images collection, 24k+ photos).
> > > 
> > > > also try to another removable drive.
> > > See above, 1st reply.
> > > 
> > > > I doubt "22.04" is the problem.
> > > It is not, since I still have not upgraded. So, rather *my* 20.04 install
> > > with dt4 - if even. I have installed lots of stuff, and restarting from a
> > > fresh 22.04 clean install might be the solution. However, restoration is
> > > still in progress, so I have to wait a little bit more.
> > > 
> > > Rgrds,
> > > 
> > > J.-Luc
> > While you  are troubleshooting, perhaps also do a memtest on the RAM. A 
> > faulty
> > RAM chip once gave me a lot of "bad sectors" on a HDD (and as they were 
> > marked
> > as such, replacing the RAM stopped it getting worse, but didn't recover the
> > "bad" sectors...)
> > 
> > In any case, I'd rule out hardware problems before upgrading to a new OS
> > version...
> > 
> > Remco
> > 
> Good idea, I will do this.😎
> The scan has finished, the partition was reported as Deleted. It was enough
> to revert it to Primary, I am able to access the whole disk correctly.
> I am currently copying the sidecars, then I will copy the raws from the
> backup disk to a new one and copy the sidecars, and finally run a test on
> the "faulty" disk.
> It may take some time, I will come back and report when done.

running a "test" on the subject disk is good, but utilizing another
storage method will give you more troubleshooting information.

run on a local disk, completely, and ensure you do not have local
problems.  then the external disk or the transfer method between it an
your computer become *very* suspect.


trouble shooting is not hit and miss.  it is more about removing concern
about the most readily available objects and then diving deeper.


-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet oftc

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] dt from repo / build

[Jean-Luc]

Le 17/08/2022 à 18:36, William Ferguson a écrit :



On Wed, Aug 17, 2022 at 10:15 AM Jean-Luc 
 wrote:


Hello,

And sorry for that maybe stupid questions, but...
I currently run dt from repos, and all works fine though some
stuff is not installed (especially tools like noise, profiling, etc.).
On a second machine (not the one I use for processing my photos
!), I compiled it using the instructions on those pages

.
However, it seems that some files are not at the same places that
those intalled from repos. Maybe it is something normal.
My questions:

 1. is it possible (and safe ?) to force the installation in the
exact same location that the offical packages ? How ?

You can do it.  I would remove the official packages first.  When you 
build specify /usr as the installation prefix


1.


 2. I found there is no stable branch, just master and numbered.

master is the current branch that all changes are merged to.  There is 
no stable branch since darktable is not a rolling release.

releases are tagged so that they can be checked out and built.

 1. If I type
git clone --branch latest --recurse-submodules --depth 1
https://github.com/darktable-org/darktable.git
it will fail, however
git clone --branch master --recurse-submodules --depth 1
https://github.com/darktable-org/darktable.git
will work. No possibility to get something else than master ?

git checkout release-4.0.0
git submodule update

This checks out the versions of the submodules used to build release-4.0

 1. In the same kind of things, a little further one can find
git checkout tags/release-4.0.0
which seems to only work with numbering, even master is not
recognized ('tags/release-master' does not correspond to any
file known by git [translated from french]).
What does this deserve ?

git checkout master takes you back to master.  Just do a git submodule 
update after you change back.


Sorry for all those questions, but I am trying to understand how
things work for this project, as it seems the commuters differ
slightly from others.

Thanks,

J.-Luc



darktable user mailing list to unsubscribe send a mail to
darktable-user+unsubscr...@lists.darktable.org



Bill

 
darktable user mailing list to unsubscribe send a mail to 
darktable-user+unsubscr...@lists.darktable.org

Thanks, Bill. 😎
I think (I hope...) I understand.

Rgrds,

J.-Luc


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] dt 4.0 corrupts disk

[Jean-Luc]

Le 17/08/2022 à 15:33, Remco Viëtor a écrit :

On mercredi 17 août 2022 15:12:35 CEST Jean-Luc wrote:

Le 17/08/2022 à 13:45, Patrick Shanahan a écrit :

* Jean-Luc  [08-17-22 06:12]:

Le 16/08/2022 à 23:17, I. Ivanov a écrit :

On 8/16/22 13:59, Patrick Shanahan wrote:

* Jean-Luc  [08-16-22 16:42]:
I would definitely try another external drive and maybe try to store
on a
local drive and move the files after finishing.

Agree with Patrick.

It is more likely the DD responds with corrupting the data because of
the operation (writing xml I expect) than Darktable actually doing
something wrong.

If it is a spin disk – you may want to check it for bad sectors. But
what Patrick suggest should take the disk out of the equation
completely.

Regards,

B

Hello,

First, it is Testdisk, not memtest - I do not know why I always mention
the
second instead of the first... 😬
And I do not know as well why I wrote the scan lasts two hours, since it
takes more than twelve. 😬😬
And, yes, does not really reflect the reality : as I have still not
upgraded to 22.04, the problem might be caused by anything else than dt
itself, so a log would have been a good starting point.
My interrogation was whether dt coul have saved a crash dump though
launched as usual - ie with no commuter, aso. The answear is obviously
no,
unfortunately.
The last time it happened I ran a full test after restoration (another
12+
hours) and no bad sector was detected.
In any case, I have a backup of the files, I just need to get the
sidecars
then I can copy to another disk and restart clean.

you are still not eliminating possibilities with your current approach.

Yes, I do, since I intend to copy the files to another disk. I just need
to retrieve my sidecars first.


try first to export to a local disk.

That might not be really relevant, the problem does not occur
systematically. Only two times since dt upgrade and heavy work
(reworking my whole images collection, 24k+ photos).


also try to another removable drive.

See above, 1st reply.


I doubt "22.04" is the problem.

It is not, since I still have not upgraded. So, rather *my* 20.04 install
with dt4 - if even. I have installed lots of stuff, and restarting from a
fresh 22.04 clean install might be the solution. However, restoration is
still in progress, so I have to wait a little bit more.

Rgrds,

J.-Luc

While you  are troubleshooting, perhaps also do a memtest on the RAM. A faulty
RAM chip once gave me a lot of "bad sectors" on a HDD (and as they were marked
as such, replacing the RAM stopped it getting worse, but didn't recover the
"bad" sectors...)

In any case, I'd rule out hardware problems before upgrading to a new OS
version...

Remco


Good idea, I will do this.😎
The scan has finished, the partition was reported as Deleted. It was 
enough to revert it to Primary, I am able to access the whole disk 
correctly.
I am currently copying the sidecars, then I will copy the raws from the 
backup disk to a new one and copy the sidecars, and finally run a test 
on the "faulty" disk.

It may take some time, I will come back and report when done.

J.-Luc


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] dt from repo / build

[William Ferguson]

On Wed, Aug 17, 2022 at 10:15 AM Jean-Luc 
wrote:

> Hello,
> And sorry for that maybe stupid questions, but...
> I currently run dt from repos, and all works fine though some stuff is not
> installed (especially tools like noise, profiling, etc.).
> On a second machine (not the one I use for processing my photos !), I
> compiled it using the instructions on those pages
> 
> .
> However, it seems that some files are not at the same places that those
> intalled from repos. Maybe it is something normal.
> My questions:
>
>1. is it possible (and safe ?) to force the installation in the exact
>same location that the offical packages ? How ?
>
> You can do it.  I would remove the official packages first.  When you
build specify /usr as the installation prefix

>
>1.
>2. I found there is no stable branch, just master and numbered.
>
> master is the current branch that all changes are merged to.  There is no
stable branch since darktable is not a rolling release.
releases are tagged so that they can be checked out and built.

>
>1. If I type
>git clone --branch latest --recurse-submodules --depth 1
>https://github.com/darktable-org/darktable.git
>it will fail, however
>git clone --branch master --recurse-submodules --depth 1
>https://github.com/darktable-org/darktable.git
>will work. No possibility to get something else than master ?
>
> git checkout release-4.0.0
git submodule update

This checks out the versions of the submodules used to build release-4.0

>
>1. In the same kind of things, a little further one can find
>git checkout tags/release-4.0.0
>which seems to only work with numbering, even master is not recognized
>('tags/release-master' does not correspond to any file known by git
>[translated from french]).
>What does this deserve ?
>
> git checkout master takes you back to master.  Just do a git submodule
update after you change back.

>
>
> Sorry for all those questions, but I am trying to understand how things
> work for this project, as it seems the commuters differ slightly from
> others.
>
> Thanks,
>
> J.-Luc
>
> 
> darktable user mailing list to unsubscribe send a mail to
> darktable-user+unsubscr...@lists.darktable.org
>

Bill


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

[darktable-user] dt from repo / build

[Jean-Luc]

Hello,

And sorry for that maybe stupid questions, but...
I currently run dt from repos, and all works fine though some stuff is 
not installed (especially tools like noise, profiling, etc.).
On a second machine (not the one I use for processing my photos !), I 
compiled it using the instructions on those pages 
.
However, it seems that some files are not at the same places that those 
intalled from repos. Maybe it is something normal.

My questions:

1. is it possible (and safe ?) to force the installation in the exact
   same location that the offical packages ? How ?
2. I found there is no stable branch, just master and numbered.
   If I type
   git clone --branch latest --recurse-submodules --depth 1
   https://github.com/darktable-org/darktable.git
   it will fail, however
   git clone --branch master --recurse-submodules --depth 1
   https://github.com/darktable-org/darktable.git
   will work. No possibility to get something else than master ?
3. In the same kind of things, a little further one can find
   git checkout tags/release-4.0.0
   which seems to only work with numbering, even master is not
   recognized ('tags/release-master' does not correspond to any file
   known by git [translated from french]).
   What does this deserve ?

Sorry for all those questions, but I am trying to understand how things 
work for this project, as it seems the commuters differ slightly from 
others.


Thanks,

J.-Luc


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] dt 4.0 corrupts disk

[Remco Viëtor]

On mercredi 17 août 2022 15:12:35 CEST Jean-Luc wrote:
> Le 17/08/2022 à 13:45, Patrick Shanahan a écrit :
> > * Jean-Luc  [08-17-22 06:12]:
> >> Le 16/08/2022 à 23:17, I. Ivanov a écrit :
> >>> On 8/16/22 13:59, Patrick Shanahan wrote:
>  * Jean-Luc  [08-16-22 16:42]:
>  I would definitely try another external drive and maybe try to store
>  on a
>  local drive and move the files after finishing.
> >>> 
> >>> Agree with Patrick.
> >>> 
> >>> It is more likely the DD responds with corrupting the data because of
> >>> the operation (writing xml I expect) than Darktable actually doing
> >>> something wrong.
> >>> 
> >>> If it is a spin disk – you may want to check it for bad sectors. But
> >>> what Patrick suggest should take the disk out of the equation
> >>> completely.
> >>> 
> >>> Regards,
> >>> 
> >>> B
> >> 
> >> Hello,
> >> 
> >> First, it is Testdisk, not memtest - I do not know why I always mention
> >> the
> >> second instead of the first... 😬
> >> And I do not know as well why I wrote the scan lasts two hours, since it
> >> takes more than twelve. 😬😬
> >> And, yes, does not really reflect the reality : as I have still not
> >> upgraded to 22.04, the problem might be caused by anything else than dt
> >> itself, so a log would have been a good starting point.
> >> My interrogation was whether dt coul have saved a crash dump though
> >> launched as usual - ie with no commuter, aso. The answear is obviously
> >> no,
> >> unfortunately.
> >> The last time it happened I ran a full test after restoration (another
> >> 12+
> >> hours) and no bad sector was detected.
> >> In any case, I have a backup of the files, I just need to get the
> >> sidecars
> >> then I can copy to another disk and restart clean.
> > 
> > you are still not eliminating possibilities with your current approach.
> 
> Yes, I do, since I intend to copy the files to another disk. I just need
> to retrieve my sidecars first.
> 
> > try first to export to a local disk.
> 
> That might not be really relevant, the problem does not occur
> systematically. Only two times since dt upgrade and heavy work
> (reworking my whole images collection, 24k+ photos).
> 
> > also try to another removable drive.
> 
> See above, 1st reply.
> 
> > I doubt "22.04" is the problem.
> 
> It is not, since I still have not upgraded. So, rather *my* 20.04 install
> with dt4 - if even. I have installed lots of stuff, and restarting from a
> fresh 22.04 clean install might be the solution. However, restoration is
> still in progress, so I have to wait a little bit more.
> 
> Rgrds,
> 
> J.-Luc
While you  are troubleshooting, perhaps also do a memtest on the RAM. A faulty 
RAM chip once gave me a lot of "bad sectors" on a HDD (and as they were marked 
as such, replacing the RAM stopped it getting worse, but didn't recover the 
"bad" sectors...)

In any case, I'd rule out hardware problems before upgrading to a new OS 
version...

Remco




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] dt 4.0 corrupts disk

[Jean-Luc]

Le 17/08/2022 à 13:45, Patrick Shanahan a écrit :

* Jean-Luc  [08-17-22 06:12]:

Le 16/08/2022 à 23:17, I. Ivanov a écrit :

On 8/16/22 13:59, Patrick Shanahan wrote:

* Jean-Luc  [08-16-22 16:42]:
I would definitely try another external drive and maybe try to store
on a
local drive and move the files after finishing.



Agree with Patrick.

It is more likely the DD responds with corrupting the data because of
the operation (writing xml I expect) than Darktable actually doing
something wrong.

If it is a spin disk – you may want to check it for bad sectors. But
what Patrick suggest should take the disk out of the equation
completely.

Regards,

B

Hello,

First, it is Testdisk, not memtest - I do not know why I always mention the
second instead of the first... 😬
And I do not know as well why I wrote the scan lasts two hours, since it
takes more than twelve. 😬😬
And, yes, does not really reflect the reality : as I have still not upgraded
to 22.04, the problem might be caused by anything else than dt itself, so a
log would have been a good starting point.
My interrogation was whether dt coul have saved a crash dump though launched
as usual - ie with no commuter, aso. The answear is obviously no,
unfortunately.
The last time it happened I ran a full test after restoration (another 12+
hours) and no bad sector was detected.
In any case, I have a backup of the files, I just need to get the sidecars
then I can copy to another disk and restart clean.

you are still not eliminating possibilities with your current approach.
Yes, I do, since I intend to copy the files to another disk. I just need 
to retrieve my sidecars first.

try first to export to a local disk.
That might not be really relevant, the problem does not occur 
systematically. Only two times since dt upgrade and heavy work 
(reworking my whole images collection, 24k+ photos).

also try to another removable drive.

See above, 1st reply.

I doubt "22.04" is the problem.


It is not, since I still have not upgraded. So, rather *my* 20.04 install with 
dt4 - if even.
I have installed lots of stuff, and restarting from a fresh 22.04 clean install 
might be the solution.
However, restoration is still in progress, so I have to wait a little bit more.

Rgrds,

J.-Luc


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] dt 4.0 corrupts disk

[Patrick Shanahan]

* Jean-Luc  [08-17-22 06:12]:
> Le 16/08/2022 à 23:17, I. Ivanov a écrit :
> > 
> > On 8/16/22 13:59, Patrick Shanahan wrote:
> > > * Jean-Luc  [08-16-22 16:42]:
> > > I would definitely try another external drive and maybe try to store
> > > on a
> > > local drive and move the files after finishing.
> > > 
> > > 
> > Agree with Patrick.
> > 
> > It is more likely the DD responds with corrupting the data because of
> > the operation (writing xml I expect) than Darktable actually doing
> > something wrong.
> > 
> > If it is a spin disk – you may want to check it for bad sectors. But
> > what Patrick suggest should take the disk out of the equation
> > completely.
> > 
> > Regards,
> > 
> > B
> 
> Hello,
> 
> First, it is Testdisk, not memtest - I do not know why I always mention the
> second instead of the first... 😬
> And I do not know as well why I wrote the scan lasts two hours, since it
> takes more than twelve. 😬😬
> And, yes, does not really reflect the reality : as I have still not upgraded
> to 22.04, the problem might be caused by anything else than dt itself, so a
> log would have been a good starting point.
> My interrogation was whether dt coul have saved a crash dump though launched
> as usual - ie with no commuter, aso. The answear is obviously no,
> unfortunately.
> The last time it happened I ran a full test after restoration (another 12+
> hours) and no bad sector was detected.
> In any case, I have a backup of the files, I just need to get the sidecars
> then I can copy to another disk and restart clean.

you are still not eliminating possibilities with your current approach.

try first to export to a local disk.

also try to another removable drive.

I doubt "22.04" is the problem.



-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet oftc

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] dt 4.0 corrupts disk

[Jean-Luc]

Le 16/08/2022 à 23:17, I. Ivanov a écrit :


On 8/16/22 13:59, Patrick Shanahan wrote:

* Jean-Luc  [08-16-22 16:42]:
I would definitely try another external drive and maybe try to store 
on a

local drive and move the files after finishing.



Agree with Patrick.

It is more likely the DD responds with corrupting the data because of 
the operation (writing xml I expect) than Darktable actually doing 
something wrong.


If it is a spin disk – you may want to check it for bad sectors. But 
what Patrick suggest should take the disk out of the equation completely.


Regards,

B


Hello,

First, it is Testdisk, not memtest - I do not know why I always mention 
the second instead of the first... 😬
And I do not know as well why I wrote the scan lasts two hours, since it 
takes more than twelve. 😬😬
And, yes, does not really reflect the reality : as I have still not 
upgraded to 22.04, the problem might be caused by anything else than dt 
itself, so a log would have been a good starting point.
My interrogation was whether dt coul have saved a crash dump though 
launched as usual - ie with no commuter, aso. The answear is obviously 
no, unfortunately.
The last time it happened I ran a full test after restoration (another 
12+ hours) and no bad sector was detected.
In any case, I have a backup of the files, I just need to get the 
sidecars then I can copy to another disk and restart clean.


Rgrds,

J.-Luc



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Ubuntu 22.04.1 and OpenCL

[Mikael Ståldal]

I have all of those (except nvidia-modprobe), and I have 
/usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1




On 2022-08-16 22:48, Šarūnas wrote:

On 16/08/2022 15.51, Mikael Ståldal wrote:
So which OpenCL library do I need? I tried to install 
libopencl-clang-dev, but it does not help.


On 22.04.1 with RTX 2070, where OpenCL works, there are following 
installed:


$ dpkg -l \*nvidia\*|grep ^ii
ii libnvidia-cfg1-515:amd64
ii libnvidia-common-515
ii libnvidia-compute-515:amd64
ii libnvidia-decode-515:amd64
ii libnvidia-egl-wayland1:amd64
ii libnvidia-encode-515:amd64
ii libnvidia-extra-515:amd64
ii libnvidia-fbc1-515:amd64
ii libnvidia-gl-515:amd64
ii nvidia-compute-utils-515
ii nvidia-dkms-515
ii nvidia-driver-515
ii nvidia-kernel-common-515
ii nvidia-kernel-source-515
ii nvidia-modprobe
ii nvidia-prime
ii nvidia-settings
ii nvidia-utils-515
ii xserver-xorg-video-nvidia-515

/usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 is part of
libnvidia-compute-515 package.



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org