Mount point does not exist

qsl

So I am attempting to chroot my drive in xfce for repairs. I am following the guide and:

ive@solus ~ $ sudo su
root@solus /home/live # mkdir /target
root@solus /home/live # lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0   2.6G  1 loop 
loop1         7:1    0   8.7G  1 loop /run/rootfsbase
sda           8:0    1  57.8G  0 disk 
└─sda1        8:1    1  57.8G  0 part 
sdb           8:16   1  28.9G  0 disk 
└─sdb1        8:17   1  28.9G  0 part /run/initramfs/live
sr0          11:0    1  1024M  0 rom  
zram0       252:0    0     8G  0 disk [SWAP]
nvme0n1     259:0    0 238.5G  0 disk 
├─nvme0n1p1 259:1    0     1G  0 part 
└─nvme0n1p2 259:2    0 237.5G  0 part 
root@solus /home/live # mount /dev/nvme0n1p1 /target/boot
mount: /target/boot: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@solus /home/live # mount /dev/nvme0n1p2 /target/boot
mount: /target/boot: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@solus /home/live # mount /dev/nvme0n1 /target/boot
mount: /target/boot: wrong fs type, bad option, bad superblock on /dev/nvme0n1, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.
root@solus /home/live # sudo su
root@solus /home/live # mkdir /target
mkdir: cannot create directory ‘/target’: File exists
root@solus /home/live # mount /nvme0n1p1 /target/boot
mount: /target/boot: fsconfig system call failed: /nvme0n1p1: Can't lookup blockdev.
       dmesg(1) may have more information after failed mount system call.
root@solus /home/live # mount /dev/nvme0n1p1 /target/boot
mount: /target/boot: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@solus /home/live #

What am I doing wrong?

Rgib

You have to mount in an already existent directory, so after mkdir /target do mkdir /target/boot
mkdir means "make directory"

qsl

Rgib I'm not sure I understand.

So in the same string I input "mkdir /target mount /dev/nvme0n1p1 /target/boot"? Or do I break them up, one after the other? What the exact input?

Sorry if this seems basic. The directions are broken up.

Rgib

From the beginning. First sudo su : it means "super-user do", it grants you all access on your system, with no security restriction (be careful). That is why after that you are logged as "root" and no more "ive"
Then mkdir /target Create a new folder, called "target" in your system
Then mkdir /target/boot Create a sub-folder, "boot" in your "target" folder
Then mount /dev/nvme0n1p1 /target/boot It grant you access to your nvme from your usb solus. You will find the content of this partition in the folder /target/boot
You will have to do the same process each time you want to mount a partition : first create a folder for it, then use the command "mount"

qsl

Rgib Ah, the string "mkdir /target/boot" wasn't in the Boot Rescue... error message.

When I move to section vi. Chroot to your Solus system:

the commands listed "mount --types proc /proc /target/proc" etc. still don't have a mounting point

live@solus ~ $ sudo su
root@solus /home/live # mkdir /target
mkdir: cannot create directory ‘/target’: File exists
root@solus /home/live # mkdir /target/boot
mkdir: cannot create directory ‘/target/boot’: File exists
root@solus /home/live # mount /dev/nvme0n1p1 /target/boot
root@solus /home/live # mount /dev/nvme0n1p2 /target/boot
root@solus /home/live # mount --types proc /proc /target/proc
mount: /target/proc: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@solus /home/live # mount --rbind /dev /target/dev
mount: /target/dev: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@solus /home/live # mount --rbind /sys /target/sys
mount: /target/sys: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@solus /home/live # mount --make-rslave /target/dev
mount: /target/dev: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@solus /home/live # mount --make-rslave /target/sys
mount: /target/sys: mount point does not exist.

alfisya

qsl what filesystem are you using? If it is BTRFS the mount command is a bit different.

Also it seems you mounted both partition at /target/boot. One of them should be on /target instead.

qsl root@solus /home/live # mount /dev/nvme0n1p1 /target/boot
root@solus /home/live # mount /dev/nvme0n1p2 /target/boot

qsl

alfisya I have no idea. It would have been the default file system for xfce. How would I check?

Woo-hoo! I made it down to "Prevent System from mounting unavailable devices...

I get this string

"  GNU nano 8.6                       /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=f1841460-5185-4b7f-9ba0-315850697e20 /              ext4    defaults   0 1
tmpfs                                     /tmp           tmpfs   defaults,noati>"

and have no idea what "Add the noauto option to the line corresponding to the unavailable device." means.
Where do I add it? What denotes an unavailable device? How do I save the file? Do I restrart just by closing terminal or is there a command?

What is the exact entry I should make?

^G Help ^O Write Out ^F Where Is ^K Cut ^T Execute ^C Location
^X Exit ^R Read File ^\ Replace ^U Paste ^J Justify ^/ Go To Line

Rgib

Here is a more step-by-step explanation.
I suppose you don't use BTRFS. If you do, ignore this message
I suppose nvme0n1p1 (1GB) is your boot partition
I suppose nvme0n1p2 (237.5GB) is your root
I suppose you don't have a separate partition for your home

1° Reboot on your Solus live-USB. It will clear all the mounts you tried before
2° in a terminal, run :
sudo su
mkdir /target
If you have a message saying "file exists", it's OK. If you don't have any message, it's OK too
mount /dev/nvme0n1p2 /target
It will mount your main partition (root) in the folder "target"
cd /target
ls
It will show you the content of the folder "target"
In the list you MUST have at least these subfolders : boot, etc, home, proc, dev, sys
mount /dev/nvme0n1p1 /target/boot
It will fill the subfolder boot with your 1GB partition. The files are not copied. If you don't know what is mount, think as if it was just some links
3° Go to the section vi. Chroot to your Solus system in this guide and follow instructions

qsl

Rgib Aye. Currently I am holding steady at the prevent mounting unavailable devices string listed above for the version of the guide I'm using. Can I just close the terminal on this? Is there anything more that needs to be done at this step?

And thank you for your help. It has been the most clear example of what to do ("That's because I did most of the work...").

Yeah, well...

qsl

Rgib And now I am here

root@solus /home/live # mount --types proc /proc /target/proc
root@solus /home/live # mount --rbind /dev /target/dev
root@solus /home/live # mount --rbind /sys /target/sys
root@solus /home/live # mount --make-rslave /target/dev
root@solus /home/live # mount --make-rslave /target/sys
root@solus /home/live # chroot /target
root@solus / # ping -c 4 google.com
ping: google.com: Temporary failure in name resolution
root@solus / # exit
exit
root@solus /home/live # cp /run/systemd/resolve/stub-resolv.conf /target/run/systemd/resolve/
cp: cannot create regular file '/target/run/systemd/resolve/': Not a directory
root@solus /home/live # cd /target/etc
root@solus /target/etc # ln -s ../run/systemd/resolve/stub-resolv.conf /target/etc/resolv.conf
ln: failed to create symbolic link '/target/etc/resolv.conf': File exists
root@solus /target/etc #

Rgib

When you failed to boot, do you had an error like "mounting something failed" or "filesystem error" ?
If no you don't need to modify fstab.
fstab is the list of filesystems to be automatically mounted when you boot. Some of them are mandatory, others are not. Adding the option "noauto" to one of them means "just skip this one".
If you have this kind of error, it will tell you where is the problem, and you can modify your fstab to skip the blocking disk.
To get help with nano, use Ctrl+G

qsl

Rgib It was the " Failed to start lightdm.service".

Made a guess that the

root@solus / # ping -c 4 google.com
ping: google.com: Temporary failure in name resolution

wasn't indicative of not having an internet connection (and it would have told me if there wasn't any).

Currently rebuild the package database, and now have the error "no space left on device" (which I suspect how this all began).

So is there a way I can explore the nvme to delete some files?

qsl

qsl Like could uninstall several flatpaks.

qsl

qsl Or worst case scenario, is there was a way I could save my downloads folder and desktop files, I could scrap this install and do a fresh install on a larger drive, and explore the current drive for the files I need to keep.

qsl

qsl Or could I copy this broken installation to a larger drive, and continue the rebuilding process?

alfisya

If you feel the system is too far gone and you have spare SSD, then a fresh install would be your best bet.
In the live environment (Solus on USB stick), you can copy any file to the spare SSD.

Attach spare SSD to your computer
Boot into the live environment
Copy your file via terminal of file manager to the spare SSD.

After all the file you deemed worth saving is already copied over to the spare SSD, you can do fresh install overwriting the old install. Make sure to use "Delete Disk" option in the installer, so no broken leftover file from the old install remain.

TO BE PERFECTLY SAFE detach the spare SSD first before doing the fresh install, so you do not accidentally overwriting the spare SSD with your backup data there. After the install is success, you can reattach it and copy back the files to the fresh new install.

qsl

alfisya That would be the nuclear option, but for now if I could just transfer some files so the rebuild could complete, it might save a lot of hassle.

So how do I mount the drive in a live environment so I can transfer files to an usb? I've been searching through the forums, but no directions as detailed as I would need them (what does "copy files via terminal of file manager" entail?). How do I mount the nvme so the live environment can see it?

Also, was there some type of warning prior to installing updates that there wasn't enough space that I ignored?

alfisya

qsl So how do I mount the drive in a live environment so I can transfer files to an usb? I've been searching through the forums, but no directions as detailed as I would need them (what does "copy files via terminal of file manager" entail?). How do I mount the nvme so the live environment can see it?

Just attach the storage device (an SSD or USB stick) to the computer. The live environment will pick up/ autodetect the storage device. Then you can open File Manager/Dolphin/Nautilus/Nemo/Thunar and copy the file as you usually do. The storage device usually will be visible in the sidebar.

qsl Also, was there some type of warning prior to installing updates that there wasn't enough space that I ignored?

Maybe? Sometimes there is an error about clr-boot-manager cannot update your initramfs, that usually means your boot partition is full.

qsl

For those playing along at home, I transferred some files and proceed with a rebuild which seemed to ultimately fail (threw a ton of error messages), and I was resigned to do a complete reinstall.

But upon restarting today, the tech gods are satisfied with my offering, and everything with the old installation just works. I have no explanation.

My takeaways- a full disk leads to some odd behavior in Solus. I should probably get on having a backup scheme.

And thanks again to Rgib who baby-stepped me through chroot.

brent

qsl But upon restarting today, the tech gods are satisfied with my offering, and everything with the old installation just works. I have no explanation.

the mysterious reboot-then-the-fubar-disappears-and-everything-in-solus-is-just-fine thing. One of Solus's greatest unexplainable and enduring feats 🙂.
Plus maybe the tech gods enjoyed enough your misery, as you speculated.
congrats