^
Not tested so far.
____________________________________________________
Sadly, trying to put my system into suspend it utterly crashed once again.
System Porteus 5.0x86-64, XFCE, kernel 5.4.30 - needed cause it is the newest kernel I managed to compile 010-nvidia-340.108-k.5.4.30-porteus-v5.0-x86_64_rava.xzm for.
When that happens, REISUB is not helping, the system state is in some kind of undefined limbo.
What I see is: longer time nothing happens - the screen turns black but by the grey it displays the monitor is still switched on trying to display just black, then a text appears in a split second - too quick to read - and then the monitor switches off, but the PC still runs. And runs, and keeps running in limbo.
Since REISUB would not work, I had to do a hard reset (via pressing the ON button > 10 seconds) to switch the PC off.
After that all internal ext? partitions had to be checked, and I had to umount the extHD8_4 ext3 partition (mounted via /dev/sdb4) manually and check it manually, but this time major damage was done to the file system. fsck told me it's not a valid ext2/3/4 system:
Code: Select all
root@porteus:~# e2fsck -b 8193 /dev/sdb4
e2fsck 1.46.5 (30-Dec-2021)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb4
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
/dev/sdb4 contains a ext3 file system labelled 'extHD8_4'
last mounted on /mnt/sdb4 on Fri Aug 26 02:50:02 2022
Why does it display "ext3 file system labelled 'extHD8_4'" but cannot fsck it?
Code: Select all
root@porteus:~# e2fsck -b 32768 /dev/sdb4
e2fsck 1.46.5 (30-Dec-2021)
extHD8_4 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
[...]
Fix<y>? yes
Free blocks count wrong for group #1 (9813, counted=9942).
Fix<y>? yes
Free blocks count wrong for group #2 (11048, counted=11128).
Fix<y>? yes
Free blocks count wrong for group #3 (9793, counted=7721).
Fix<y>? yes
Free blocks count wrong for group #4 (8748, counted=6420).
Fix<y>? yes
Free blocks count wrong for group #5 (8022, counted=7948).
Fix<y>? yes
Free blocks count wrong for group #6 (6676, counted=7270).
Fix<y>? yes
Free blocks count wrong for group #7 (2181, counted=5986).
Fix<y>? yes
Free blocks count wrong for group #8 (6013, counted=12352).
Fix<y>? yes
Free blocks count wrong for group #9 (8722, counted=9654).
Fix<y>? yes
Free blocks count wrong for group #14 (12802, counted=8501).
Fix<y>? yes
Free blocks count wrong for group #15 (21547, counted=9004).
Fix<y>? yes
Free blocks count wrong for group #16 (8692, counted=7908).
Fix<y>?
[...]
Free inodes count wrong for group #3427 (8192, counted=6030).
Fix<y>? yes
Directories count wrong for group #3427 (0, counted=195).
Fix<y>? yes
Free inodes count wrong for group #3428 (8192, counted=6031).
Fix<y>? yes
Directories count wrong for group #3428 (0, counted=76).
Fix<y>? yes
Free inodes count wrong for group #3429 (8192, counted=5948).
Fix<y>? yes
Directories count wrong for group #3429 (0, counted=13).
Fix<y>? yes
[...]
Free inodes count wrong for group #3668 (8192, counted=7182).
Fix<y>? yes
Directories count wrong for group #3668 (0, counted=210).
Fix<y>? yes
Free inodes count wrong for group #3683 (7635, counted=7644).
Fix<y>? yes
Directories count wrong for group #3683 (213, counted=209).
Fix<y>? yes
Free inodes count wrong for group #3692 (8056, counted=8045).
Fix<y>? yes
Free inodes count wrong (30134300, counted=30138671).
Fix<y>? yes
extHD8_4: ***** FILE SYSTEM WAS MODIFIED *****
extHD8_4: 409297/30547968 files (56.4% non-contiguous), 72631851/122168916 blocks
Hopefully no data loss occurred.
Code: Select all
root@porteus:~# e2fsck /dev/sdb4
e2fsck 1.46.5 (30-Dec-2021)
extHD8_4: clean, 409297/30547968 files, 72631851/122168916 blocks
root@porteus:~# mount /dev/sdb4
root@porteus:~# ls /mnt/sdb4
Porteus_modules backup-rm.sh boot sound
backup backup-webm.sh extHD8_4 tmp
backup-avi.sh backup.sh extHD8_4.fsck.txt video
backup-mp3.sh backup.viewnior.weiter intHDD1_2.rebuild welt
backup-mp4.sh backup2 kamera
backup-mpg.sh bin lost+found
Root filesystem on extHD8_3
looks okay.
The reason seems to be the lack of usable memory.
This PC "only" has 4GB of RAM, and via SWAP I have this added:
Code: Select all
root@porteus:/Lsfind# type sx
sx is a function
sx ()
{
echo $(date +%d.%m.%Y\ %H:%M:%S) ____________________________________________________________;
{
read firstLine;
echo "$firstLine";
while read f t s u p; do
let "s2 = $s / 1024";
let "u2 = $u / 1024";
printf '%-40s%-16s%-8s%-8s%-8s\n' $f $t $s2 $u2 $p;
done
} < /proc/swaps
}
root@porteus:/Lsfind# sx
26.08.2022 01:28:32 ____________________________________________________________
Filename Type Size Used Priority
/dev/sda6 partition 4607 0 -2
/dev/zram0 partition 774 0 100
Is there a way the system warning me when swap via partition and zram0 has too much use that all that not fits into the physical RAM, ow whatever reason there is for the PC to crash when SWAP is too much in use instead of utterly crashing and risking data / partition corruption coming with each such crash?
Also, even when Port crashes, why is it so utterly destructive that not even REISUB works?