You are not logged in.
I would *assume* that a merged /usr would have moved everything in /sbin to /usr/sbin and replaced /sbin with a symlink to /usr/sbin (and similar for /bin, /lib, etc). But that's probably too simple for the designers to think of.
You should only quote the part of the post you are responding to, if that's not obvious from context.
The only case for quoting all of a post is a small (~1 line) post several posts back in the thread to indicate which post you are responding to.
Is there a /install/gtk/initrd.gz in your / or /boot ? If there's a /initrd.img on your system is it a symlink to somewhere?
I'm not an expert, but I know that the system loads an initrd.img early in boot processing (possibly compressed). So I'd expect that entry to point to the one the system should use. So removing that entry might stop your system booting.
Does your /etc/default/grub say anything like:
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
If so try that.
Good. I hope that gets a response, I've reached the limit of my debugging skills in this area.
Post that to the github discussion. It might point then towards the bug. (Sorry if you'e already done that).
zombie processes are processes that have been terminated, but not reaped by their parent. So look at the PPID (3339 in the first post) with ps -fp 3339 (replace 3339 which whatever the current PPID is). That should tell you what started them, which is probably where the bug is.
See man ps and search for zombie for details.
Is there a /boot directory? I assume you are running as root so will be able to write to /boot
That's all I can think of, but sometimes checking silly things can find silly problems.
Since there are no colors with "ls" inside xfce's terminal
Run alias
On my system the last line of output is
alias ls='ls --color=auto'
And my .bashrc sets that. I hope this gives you a clue.
What happens if you tell it to use googlemail.com instead of gmail.com ? I have one system using kmail where it insists on using the wrong type of auth for gmail.com but I can get it to work with googlemail.com (it's kmail being "clever" that causes the problem). I can't check details on that system just now though, sorry.
That took quite a lot of puzzling to work out.
It depends what your old graphics cards are. And if you just want them for screen display or want to use CUDA.
Obviously "nvidia-legacy-390" will only be needed for Nvidia cards. And it will be needed for CUDA.
I'd suggest trying out a live DVD/USB which doesn't have those drivers but does have nouveau. Or post a list of what cards you have.
But the locate result came up repeatedly, seems that it could find the hidden files.
From man locate
locate reads one or more databases prepared by updatedb(8) and writes file names matching at least one of the PATTERNs to standard output, one per line.
So if updatedb ran when the filesystem was not mounted it would find the "hidden" files and put them into the database. So running locate repeatedly would always show them, until the next updatedb run.
I think what fstab says may be a red herring. What seems to have happened is that the mount point is a directory in your root filesystem, and some files and directories have been moved into there when the /media/storage filesystem is not mounted.
To recover I suggest:
df -k /media/storage
If the filesystem is mounted there unmount it, and re-check with df -k /media/storage to make sure it's not mounted now.
As root:
cd /media
ls -al
Make sure there is not a storage2 dir already!
mv storage storage2
mkdir storage
Then storage2 will contain all the recovered data and the process of mounting the filesystem when needed should still work.
I've had to get at data buried under a mount point *without* unmounting the filesystem. But I would not recommend doing that unless you fully understand the process (NFS doesn't cross mountpoints, so mounting the root filesystem via NFS lets you get there. But it's a tricky process.)
Read the man page for env.
#!/usr/bin/env python3
Will only work if python3 is in it's $PATH. Try which python3 to make sure it's installed on your system.
I'm not sure what's in non-free now that they moved the firmware.
Nvidia's proprietary drivers etc (which you need to run CUDA apps) should be in there.
First try running memtest86 for a few hours. Run it single threaded first. If it doesn't hang or report any faults try it again multi threaded. If memtest86 crashes as well then the OS must be innocent.
Next boot Linux and run watch sensors in a terminal window. That will show how hot the CPU etc are. If it gets over 100C then check all fans are OK, there's no fluff on the CPU, etc.
Could someone run adequate --all on Cerebus or Daedalus? I got a load of warnings on my system but it's ASCII and installing Nvidia CUDA support may have caused some of them (as well as other things I've had to mess with when recovering from a disk failure).
I've just found (from an article in Linux Magazine) that there's a program called adequate which sanity checks packages for violations of Debian package guidelines.
Install with apt-get install adequate and read it's man page for details (it won't usually need to be run as root). From a quick check it should find various packaging errors, although there can be false positives. And it only checks if a package is correctly packaged, not if it actually does what it is supposed to. But it looks worth adding to recommended workflow.
Btw, if systemd theoretically was the lesser of two evils, what the hell has this world become!
Presumably the only other choice would be Windows.
Does the path to the directory have spaces in it? That could confuse things.
Try:
ls -A /media/charon/seagate backup plus drive/dr web
If that gets similar errors try:
ls -A '/media/charon/seagate backup plus drive/dr web'
Putting quotes round the path should stop spaces in the name causing problems.
Assuming the directory really is empty (ls -A should return nothing if it is empty) try:
rmdir '/media/charon/seagate backup plus drive/dr web'
And similar for renaming directories.
hunter@ryzen-rig:~$ ls -l /dev/video* crw-rw----+ 1 root video 81, 0 Sep 12 08:34 /dev/video0 crw-rw----+ 1 root video 81, 1 Sep 12 08:34 /dev/video1
Check your ID is in the video group. id should tell you. Post output from it if not sure.
When you see an example command starting with a $ don't enter the $, just the rest of the command. It's usually the terminal prompt.
In the unlikely event you did need to enter the $ the poster would tell you explicitly.
My first thought would be to patch the fail2ban initscript to always return success. Eg put exit 0 near the start of it.
How much memory does the system have? It might well be that systemd uses a LOT more memory, so the system starts page thrashing.
Either way it's nice to have another objective argument against systemd.
It used to be easy with gksu thunar but gksu was removed/deprecated years ago. Search and there might be current alternatives.
Try sudo thunar in a terminal window. Any way to run thunar as root *should* have the desired result. But I've not tested it.
If you can't log in to the GUI try ctrl-alt-f1 (press all 3 keys at once, in that order) which should get you to a text console where you can log on and try to fix things.
Next time you try to install something *always* do a simulation run first and check what it says it's going to do.