You will need to use manjaro-chroot from the Live installer, to give output of the installed system. Once in that environment, please give the output of:
cat /etc/fstab
… as previously requested. Thank you.
For completeness, this is the manjaro-chroot command:
sudo manjaro-chroot -a
If you should need to perform boot operations, such as replacing Grub, follow directions found in Restore the GRUB Bootloader.
I hope this helps.
manjaro-chroot -a will get you in to your installation so you can post the details requested in this thread.
df -h will show available HDD space. Also important. Please post that here as well.
N.B. When you are running your installed OS (not the Live USB):
watch -n 30 free -h might be useful to keep an eye on your memory usage. Browsers eat RAM for lunch when watching YouTube etc…
When RAM gets low, restart the browser. This usually works (for me) several times before it chokes … I can get at least a few weeks constant use before a reboot is needed this way.
Also, what @soundofthunder said 
They provided an inxi from a Live USB.
SWAP is not enabled on live media by default.
It also doesnt show any partition data.
Whereas it appears their original system did/does have some SWAP:
Ah, didn’t spot that. That’ll teach me for skim-reading without my goggles on!
N.B. I edited my previous post to tidy it up.
Good morning and thanks for the replies. I restored Grub and managed to get into the system: 15 minutes to start, apps take biblical times to start and use them, it’s very, very, very, very slow, impossible to use it. Below are the outputs you requested.
~ sudo manjaro-chroot -a ✔
==> Mounting (ManjaroLinux) [/dev/sda7]
--> mount: [/mnt]
--> mount: [/mnt/boot/efi]
--> mount: [/mnt/home]
[manjaro /]# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=8415-4124 /boot/efi vfat umask=0077 0 2
UUID=4fb222bb-cc4f-4803-a376-819e074d82c4 / ext4 defaults,noatime 0 1
UUID=a3dc1290-4cd8-4e21-8d9f-d4946224c56c /home ext4 defaults,noatime 0 2
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
[manjaro /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda7 40G 19G 19G 50% /
/dev/sda1 96M 32M 65M 33% /boot/efi
/dev/sda8 98G 33G 61G 35% /home
udev 3.9G 0 3.9G 0% /dev
shm 3.9G 0 3.9G 0% /dev/shm
run 3.9G 0 3.9G 0% /run
tmp 3.9G 0 3.9G 0% /tmp
overlay 5.8G 333M 5.5G 6% /etc/resolv.conf
[manjaro /]#
There are no obvious issues in /etc/fstab; at least that’s ruled out.
Is your desktop portal installed? I don’t know which DE you use, so can’t be more specific than saying you can check with:
pamac search --installed desktop-portal
Where did this come from? Kind of unusual if not wrong…
Try the following IF @Mirdarthos suggested command reveals that xdg-desktop-portal-gnome is installed:
sudo pacman -Rdd xdg-desktop-portal-gnome
sudo pacman -S xdg-desktop-portal-kde
More information: Stable Update 2023-06-04 under the heading Many applications (firefox, thunderbird, telegram, etc) slow to start on desktops other than Gnome.
However, I don’t see that this would necessarily cause the crash you describe.
Edit: Command updated to the kde backend.
This one 
, specifically:
/dev/shm is nothing but implementation of traditional shared memory concept. It is an efficient means of passing data between programs. One program will create a memory portion, which other processes (if permitted) can access. This will result into speeding up things on Linux.
shm / shmfs is also known as tmpfs, which is a common name for a temporary file storage facility on many Unix-like operating systems. It is intended to appear as a mounted file system, but one which uses virtual memory instead of a persistent storage device.
Reference: https://www.cyberciti.biz/tips/what-is-devshm-and-its-practical-usage.html
Along with:
Makes it look like this is still all from a Live Environment.
Hi, as a DE I use updated KDE, in fact I think the latest update made on Sunday, if I remember correctly, is the origin of the problem in question.
[manjaro /]# pamac search --installed desktop-portal
xdg-desktop-portal-kde 5.27.8-4 extra
A backend implementation for xdg-desktop-portal using Qt/KF5
xdg-desktop-portal 1.18.0-2 extra
Desktop integration portals for sandboxed apps
[manjaro /]# sudo pacman -Rdd xdg-desktop-portal-gnome
error: target not found: xdg-desktop-portal-gnome
[manjaro /]# sudo pacman -S xdg-desktop-portal-gtk
resolving dependencies...
looking for conflicting packages...
Packages (1) xdg-desktop-portal-gtk-1.14.1-3
Total Download Size: 0.11 MiB
Total Installed Size: 0.48 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages...
xdg-desktop-port... 113.7 KiB 160 KiB/s 00:01 [#########################] 100%
(1/1) checking keys in keyring [#########################] 100%
(1/1) checking package integrity [#########################] 100%
(1/1) loading package files [#########################] 100%
(1/1) checking for file conflicts [#########################] 100%
(1/1) checking available disk space [#########################] 100%
:: Processing package changes...
(1/1) installing xdg-desktop-portal-gtk [#########################] 100%
Optional dependencies for xdg-desktop-portal-gtk
evince: Print preview
:: Running post-transaction hooks...
(1/3) Arming ConditionNeedsUpdate...
(2/3) Refreshing PackageKit...
Error connecting: Could not connect: No such file or directory
error: command failed to execute correctly
(3/3) Updating the desktop file MIME type cache...
[manjaro /]#
Uninstall the xdg-desktop-portal-gtk backend. The example was given conditionally, based on whether xdg-desktop-portal-gnome was found – it isn’t needed on KDE. Plus, I neglected to change the second command to -kde as it should have been.
Regardless of this, neither command was needed. Uninstall with:
sudo pacman -R xdg-desktop-portal-gtk
OK done. Any other suggestions for solving the problem?
Without your help I won’t be able to exhume Manjaro, if you think there are no solutions tell me I’ll reinstall the system, I have some data I need inside the PC. Thank you.
manjaro-chroot -a ✔
==> ERROR: No Linux partitions detected!
At this point I think the SSD is gone.
What is the output of:
sudo blkid
… from within the chroot environment?
~ sudo blkid ✔
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/mapper/ventoy: BLOCK_SIZE="2048" UUID="2023-04-21-10-04-39-00" LABEL="MANJARO_KDE_2210" TYPE="iso9660" PTTYPE="dos"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="VTOYEFI" LABEL="VTOYEFI" UUID="C559-2E5D" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="e1d2cc2e-02"
/dev/sda1: LABEL="Ventoy" UUID="BC9E-47E4" BLOCK_SIZE="512" TYPE="exfat" PTTYPE="dos" PARTUUID="e1d2cc2e-01"
/dev/loop3: TYPE="squashfs"
Your SSD drive may have been disconnected from the SATA socket. Check that the connection is firm; and swap the cable in case it’s damaged. If the SSD still doesn’t appear in blkid output after that, then yes, a complete reinstall might be your only option (if the SSD is undamaged).
I connected an SSD that I have for backup and it was recognized immediately. it means that the SSD with Manjaro is damaged. but I wonder, how is this possible? without any warning! it is an INTENSE SSD with 2 years of life.
I wonder if sudo smartctl -a /dev/sda will reveal anything? … as for the disappearing data, SSDs apparently can fail in this manner, unfortunately.
I doubt that would reveal much when the SSD doesn’t appear to be detected at all; it seems kaputski, from information provided.
Perhaps it will make a fine paperweight.