Hello. Thanks for reading my topic.
Here Lubuntu 24.04.3 totally updated 30-10-2025.
The OS load and work correctly, but when connecting an notebook WD HD 500 GB in OS boot show an message about an job being done an that HD not being filesystem checking and have an duration of wait of 1:30 minute and then show error message in that HD.
When the OS is totally loaded is started GSmartControl and the that HD is reported as good status.
The problem is when accessing an partition in that HD … when trying read an big file of more 10 GB the Lubuntu OS and LXQT are closed and the OS is in terminal GUI in #root wainting an command. Not is possible ALT+TAB as if the Lubuntu LXQT sessions was totally closed. That weird behavior happen when trying access to files in that HD.
How avoid it ?
In moment I see is better enter in OS recovery mode and in terminal copy all files in that HD.
Other detail is before conecting that HD the OS had 2 WD HDs loading in boot configured in fstab being removed one to connect that notebook HD.
That HD has more of 10 years and was few used … less of 500 hours of usage …
Without giving us any details about the message, we’re unlikely to know what exactly is happening, or at least I can’t. The HDD is also vague details; as knowing what file-system(s) involved are probably essential as well.
I don’t have an external HDD here to explore, but you don’t give fs specifics anyway (and if I had one, it may not match). Later today I maybe able to explore; but I may not have a file of 10GB+ in size anyway; as I didn’t detect anything that big on my network shares on this box (I don’t backup to large files & don’t have large databases of that size here).
Where I’d be exploring is probably
are there any crash files; ie. in /var/crash that have metadata time/date stamps matching the problem?
any clues in system logs, ie. dmesg, journalctl for starters
You mention reading a file that large; but give no clues as to how you’re reading it; ie. are you grepping it? loading it into an app if so what app? what type of file? etc.
If a HDD was failing; your scanning SMART data should have found it, but I’d expect noise from the drive, and hangs (esp. if a consumer grade HDD as they tend to retry many many times so they’re not warranty claims) more than crashes, but again system logs should show that detail easily.
The HD use one partition BTRFS
In /var/log/
dmesg and lastlog not has any detail about actions done in that HD.
I will read any log in /var/crash and dmesg journalctl and if possible will be posted here.
The crash happen when I using PCManFM-QT or Double Commander and try to do an test reading an large size and the LXQT sessions is closed.
SMART report good status. False message.
Is how when reading an file and has errors in the area of disk crash anything in the OS doing LXQT to be closed.
The program pcmanfm-qt is both a file manager, and also handles much of what we see as a desktop for LXQt (excluding panel; that’s lxqt-panel); so should it crash when used as a file manager having the whole LXQt desktop close isn’t that surprising to me (suspicion though; I don’t know the cause)
For example I don’t have any pcmanfm-qtfile manager windows open, but a quick [ps -elf] scan shows
as that is the program that puts my wallpaper on my desktop, the icons that I have on one of my screens etc.
I don’t know the double commander file manager either, or probably more critically I don’t know what you mean by “test reading an large size”. I do wonder if RAM got filled up, your swap maybe also filled, and thus the system (eg. systemd-oomd) killed the offending RAM clogging process, which is causing your issue.
If systemd-oomd is involved; I’d expect to see evidence of that in the systemd journal though (as per my prior reply)
Double Commander is amazing file manager.
The read test is doing checksum hash.
I will try to read the file using terminal in OS recovery mode and then post the result.
The issue closing LXQT not is related with file manager not being possible read any file. Is error in disk closing anything then close LXQT session.