If not, then just tell me. I'm only learning this stuff.

I think we have now established that 1) he is not going to reproduce it, ever. And 2) the information provided seems to point to a problem with crypto, not with ext4, not with Sigil and not with his hardware, but 3) we can never be sure and this isn't going anywhere ever.

That is, if we think that what broke, broke essentially (the problem, whatever it was, broke everything that it could, namely all encrypted filesystems) and not accidentally (it could have broken any filesystems, but it just happened to break these particular ones this time).

We have also established that 4) there is no way for Devuan or any distro of any size to reproduce a problem like this, also based on the information given, but also because no distribution is going to start a hunt for a random problem based on one report. Even if there was widespread property damage or loss of life, there would simply be not enough information to do anything. There simply isn't anything obviously wrong with ext4, and it would be his problem to prove otherwise.

I personally feel that a distro does not look bad if it can't do anything about this. But a distro might look bad to some people in some cases if it has many critical bug reports hanging endlessly, because someone might think that there are serious problems the distro thinks it ought to fix but for some reason hasn't been able to. It muddies the waters, so to speak.

Might not be a terrible idea to implement something similar for the Devuan bugtracker.

No . . . bad idea. The Devuan bug tracker is for bugs in packages that Devuan provides. I know you know this so why muddy the waters . . . ;D

That particular bug is never going anywhere and might as well be closed with worksforme or something like that.

Many projects automate this with a "janitor" bot, e.g.

Might not be a terrible idea to implement something similar for the Devuan bugtracker.

The first obvious difference is that the person who reported that bug could and did reproduce it. With a report like yours, any distro, no matter how large, would have simply done the same thing Devuan did: asked you for more information.

There simply exists no way for them to reproduce your bug. What should they do? Run ext4 in random configurations and see if they encounter it? Well this is what millions of people are doing all over the world anyway. Every ext4 user is already technically hunting for your bug without even knowing it.

As far as I know, every person in this project (referring to Devuan) is a volunteer. And the average person who will respond to you on this forum is either a) doubly a volunteer (because not even appointed volunteers respond here in any official capacity, as far as I know). Or b) only a user like you. The project's response is what you got in January of 2020. And the best thing you're going to get from any developer in any corporation or project to this issue is either moreinfo or unreproducible.

If photorec could not find any of your pictures then either a) you ran it on the raw, encrypted device. Or b) you ran it on the logical, unencrypted device, but something had overwritten the files. Did you still see the decrypted devices (nvme_crypt and sde1_crypt) after the fact? If you did not then it's possibly the crypto that failed (ergo not the filesystem).

Even so, I doubt that EXT4 is the culprit in this case. My intuition is telling me that you may have somehow gotten a hold of a trojanized (malicious) version of Sigil, as unlikely as that may seem. Since that's probably not the case, perhaps you were just hit with a rare, nasty bug (though not necessarily in ext4).

This information may be helpful:

How to verify that package-installed files match originals?
https://unix.stackexchange.com/question … -originals

This is not the customers who do the work, but developers

Ahh, I see. You think you are a "customer" for the operating system you received for free.
That explains everything... Or at least everything prior to the unhinged drivel in your last post anyway.
Perhaps read up on how FOSS development works, and how to file actionable bug reports?

Anyhow, bye now, have fun.

Now just ignore me, because I will ignore you, as you need to get treatment.

Nah - nah - nanah - nah . . . Good grief . . . Maybe it's time to grow up?

What you wrote until now is pretty illogical.

Moreover, you fail to understand what I am telling.

LOL. I hope you are not a developer, because what you wrote is totally dumb. This is a big part of any developer work: try to fix bugs, that are not so obvious to find. And you know what? This is not the customers who do the work, but developers…

You wrote "you appear". Indeed, this is your interpretation. Not the truth. Obviously, you did not take the time to read what I have stated before.

Ok, now I can affirm that you are a troll, because you are going to a kind of trial of intent.

Now I can affirm that you are a troll that did not read everything, yet acting very badly.

What are you talking about?

Where I have written that I was expecting anything from Devuan developers? Are you dumb? Standardpoodle was amazed, not me.

It is a fact that bigger projects like Debian, Ubuntu, Fedora, etc. handle better this kind of issue. Here an issue with Fedora and XFS:

- https://bugzilla.redhat.com/show_bug.cgi?id=2208553

And it is a fact that here we have nothing after 4 years. Is this a complaint? NO JUST FACTS.

Now just ignore me, because I will ignore you, as you need to get treatment.

there should be some investigations done... there is no investigation... because there is no resource available.

The most available resource for initial investigation of a bug only you have encountered is... You.

You appear to want want somebody else to take responsibility for this, yet you have so far:
* Reported it to a team that is not directly responsible for the component in question, with minimal information, no reproduction steps, and no logs or debug output.
* Tried to divert discussion and tracking away from the official channels (bugtracker & mailing lists) to a user forum (which few developers frequent).
* Failed to follow up when asked to reproduce the problem with an untainted kernel (taint disables kernel debugging), or engage on the bugtracker at all beyond the initial report. (hint: replies to the bugtracker mail people who might care, forum posts do not)
* Continually stated a "suspicion" that this is a software problem that "somebody" should investigate, yet focused your own cursory "investigation" entirely on hardware.

Why exactly do you expect the Devuan developers, of all people, to work on reproducing a "bug" you "suspect" you have found, when you yourself are apparently unwilling to do the same? Do you want them to feed and burp you as well?

It is not at all uncommon, regardless of the size of a project, for a bug report to remain that - just a report - until either the reporter or somebody else with the same problem provides enough information to reproduce the issue. Developers are not psychic, and what cannot be seen cannot be fixed.
Only then can it move to [confirmed] and work on finding the cause begin.

zero wrote:

I still suspect EXT4, but cannot prove this.

Isolated report from a single user (vs. the uncounted thousands running EXT4 daily), and no proposed mechanism or reliable reproduction: highly likely to remain an unproven suspicion.

This is why I can only suspect EXT4…

And as long as EXT4 is only suspected, there should be some investigations done. So, for now, there is no investigation, not because this is, for sure, an EXT4 bug, rather because there is no resource available. Hence, the bug report stales…

Take a look at Debian, Ubuntu, etc. In these other bigger projects, we have at least some feedbacks, etc. Here we have nothing after 4 years.

+1

I was about to post the same thing/idea.

Best,

A.

Can a report be in a moreinfo state for years?

A bug can be in [moreinfo] for as long as it takes for the submitter to provide more info as requested... Or until people get tired of waiting.
The last comment was "Did you reproduce it on an untainted kernel?", to which the response so far has been *crickets*.

Isolated report from a single user (vs. the uncounted thousands running EXT4 daily), and no proposed mechanism or reliable reproduction: highly likely to remain an unproven suspicion.

If this is a bug in EXT4 (and frankly I very much doubt that) it should be punted upstream to the kernel mailing list. Investigating esoteric kernel bugs is not Devuan's responsibility.

I repeat:

• different controllers

• different brands

• two different disks

• two different technologies: one HDD and one nvme

• more than 100GB have been loss, while the system has max theoretically up to 32GB of memory

but they all have in common EXT4.

So, I still suspect EXT4, but cannot prove this. Maybe I am totally wrong, but why EXT4? Well, there are some infamous known bugs:

- https://bugs.launchpad.net/ubuntu/+sour … bug/317781
- https://lore.kernel.org/lkml/50882787.3 … home.de/T/
- https://bugs.debian.org/cgi-bin/bugrepo … bug=785672

Unfortunately, Devuan team seems to be too small to handle this kind of issue.

I am not especially interested in this particular bug, but I have always wondered what policies distros have for hanging bug reports. Can a report be in a moreinfo state for years? Has everyone forgotten this, or is someone trying to reproduce it?

I take it that in reality there wasn't an attempt to reproduce it, neither with a tainted nor with an untainted kernel. I am sorry for the loss of data that happened, but this stands now, four years later, as an act of God, strike of a cosmic ray or a butterfly flapping its wings in Japan and causing a data loss halfway across the globe.

Bug reports by definition can't do anything for disasters that probably only ever happen once. Unless the cause is known beforehand.

If there is a known cause, I'd suggest that something happened to the crypto key. It was altered in memory somehow and some important part of the disk's data or the on-disk representation of the key got overwritten. That wouldn't explain though why two drives were lost.

Were the disks physically fine afterwards?