it’s an external USB SSD [kingston A4OO 24O GB]
The syslog is added to the ticket already, I just added them [syslog and syslog.old] a while ago.
Nope, I didn’t do memetest yet. Didn’t know about it. Just did the ‘checkfs’. But it’s strange as this only happens with this drive and Haiku so far. Right now I’m using the Windows USB SSD, though this is WD, without issues. The Linux one is a Seagate SSD, also USB, and no issues neither.
I’m really puzzled by this issue. It’s the first time something like this happens, and I have several USB pendrives with Haiku that never gave me such PITA.
It does seem like the incredibly vague “General system error” is shown in more cases than it should, like in some simple errors when using pkgman. It might be nice if more specific errors could be returned if possible. Something user visible like pkgman (even if is a more advanced Terminal application) should never show the useless “General system error”. It is also disappointing it shows in Screenshot. Probably no one really tested against a bad disk.
Having said this if I see cases of non-specific errors like this I will try to fix them myself.
Other year I would take this into consideration. This year, at least until now, summer hasn’t been that hot. It usually reaches 46°C or even 48°, though , let’s hope it stays like this, below 38°C.
Anyway, I’ll be watching temperature and if it affects in any way…
@leavengood, more details on the issue would be great in order to report it properly. If could save the debug report of anything we would have some info besides the syslog. But as shown on one of the screenshots, saving the debug report also crashes, which is quite odd as I have no way to get more info on how and why the failure appears.
I’m not sure if this will help you much, but maybe as sort of a “teaching moment” I could explain why the Screenshot app at least is showing “General system error”. In the main window there is a _SaveScreenshot private method. Within that method there are a few places which call _DisplaySaveError. I think the one you are seeing is from line 683, which is logging the result of a Utility class Save method. Within that method there are several places which return B_ERROR, which is “General system error” when made into a string. What might be better (that might help pinpoint your problem) is for more specific errors to be returned, or maybe some more context provided in the error message. In your case I suspect that the File’s InitCheck on line 110 is failing, and maybe whatever error InitCheck is returning would provide more detail, but rather than return that it returns B_ERROR. Though it is still probably something generic like “can’t open file” or whatever.
So something is definitely weird with either your disk or how Haiku is trying to use it.
My main complaint in my previous message is that I suspect a lot of Haiku code returns B_ERROR in places where a more specific error would be better to help the user. I see this too in Go code at work so it isn’t surprising and most of it comes from not really testing the error cases very much. Some like having a bad disk are kind of hard to test though
Check whether you have alot work dirs that are full of extracted archives in your haikuports tree if you’ve been building alot of deps?, if it’s the case, go over them one by one in terminal history and delete them by adding the -c flag before the app names and then run checkfs /boot and see if this fixes the issue.
That’s good to know As an engineer, I was always puzzled by Linux’s overcommiting policy and the OOM killer (randomly pick a process to kill if out of memory). Bizarre. Good to see that Haiku has a sensible policy.
, let’s hope it stays like this, below 38°C.
As an engineer, I was always puzzled by Linux’s overcommiting policy and the OOM killer (randomly pick a process to kill if out of memory). Bizarre. Good to see that Haiku has a sensible policy.