Re: [darktable-user] dt 4.0 corrupts disk
* 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 4.0 corrupts disk
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 4.0 corrupts disk
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
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
* 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
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] dt 4.0 corrupts disk
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 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 [08-16-22 16:42]: > Hello, > > dt 4.0 repo / Ubuntu 20.04 LTS / Dell E5540 16 GB RAM / 1To SSD, photos on > external DD. > > This is the second time this happens since running dt 4.0 : pasting > development to a series of photos, dt suddenly freezes and nothing responds > anymore. > After over one hour waiting in vain, I have to kill dt. Then, the external > DD displays garbage and cannot be accessed anymore. So I have switch the > computer off. > When I restart it, te DD is no more mountable, nor accessible by Gparted. > The only way to read it is memtest, which sees the partition and the files > but, in the second part, detects inconsitency in sectors sizes. > It takes about two hours before the scan is finished, so I can copy the > backup fat onto the main one, and all is fine again. > I hope it will end soon, so I can check all ran fine, but this is how I did > the first time. > The question is : is there a chance dt has stored some crash report > somewhere, so I can attach it when I create the bug report ? > I would definitely try another external drive and maybe try to store on a local drive and move the files after finishing. -- (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
You can run it from terminal darktable -d all man darktable for options. Maybe it would be good to redirect the output to a file something like this should work, but I haven't tested it. darktable -d all >> mylog.txt Regards, B On 8/16/22 13:41, Jean-Luc wrote: Hello, dt 4.0 repo / Ubuntu 20.04 LTS / Dell E5540 16 GB RAM / 1To SSD, photos on external DD. This is the second time this happens since running dt 4.0 : pasting development to a series of photos, dt suddenly freezes and nothing responds anymore. After over one hour waiting in vain, I have to kill dt. Then, the external DD displays garbage and cannot be accessed anymore. So I have switch the computer off. When I restart it, te DD is no more mountable, nor accessible by Gparted. The only way to read it is memtest, which sees the partition and the files but, in the second part, detects inconsitency in sectors sizes. It takes about two hours before the scan is finished, so I can copy the backup fat onto the main one, and all is fine again. I hope it will end soon, so I can check all ran fine, but this is how I did the first time. The question is : is there a chance dt has stored some crash report somewhere, so I can attach it when I create the bug report ? Thx, J.-Luc 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
[darktable-user] dt 4.0 corrupts disk
Hello, dt 4.0 repo / Ubuntu 20.04 LTS / Dell E5540 16 GB RAM / 1To SSD, photos on external DD. This is the second time this happens since running dt 4.0 : pasting development to a series of photos, dt suddenly freezes and nothing responds anymore. After over one hour waiting in vain, I have to kill dt. Then, the external DD displays garbage and cannot be accessed anymore. So I have switch the computer off. When I restart it, te DD is no more mountable, nor accessible by Gparted. The only way to read it is memtest, which sees the partition and the files but, in the second part, detects inconsitency in sectors sizes. It takes about two hours before the scan is finished, so I can copy the backup fat onto the main one, and all is fine again. I hope it will end soon, so I can check all ran fine, but this is how I did the first time. The question is : is there a chance dt has stored some crash report somewhere, so I can attach it when I create the bug report ? Thx, J.-Luc darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
