• 0 Posts
  • 20 Comments
Joined 1 year ago
cake
Cake day: June 3rd, 2023

help-circle

  • I’m not sure what’s going on, I can think of a couple things worth checking.

    First I would make sure that all the files are being copied over properly. In a terminal window, run ‘ls -la /home’ and ‘ls -la /new_home’ or ‘ls -la /old_home’ and compare the outputs. Both should be the same and have a folder with your username. Check inside the user folder as well by appending ‘/username’ to the command (ex: ‘ls -la /home/Doctor_Rex’ but use your linux username).

    The letters on the left (rwxr-xr-x or something similar) are permissions and should be the same. Continuing across the line there’s another number that isn’t important and then it should say your username twice. If it says “root” you need to update the owner of the files. this can be done by running ‘sudo chown -r username:username /home/username’ where “username” is your linux username.

    Lots of configuration settings are stored in files or directories that start with a ‘.’ and are hidden by most file managers and ‘ls’ by default. If these are missing it’d cause problems.

    If everything looks the same, you could try logging in from a TTY. This won’t start a GUI, but it will allow us to see if you can log in at all. You can switch to another TTY by pressing ctrl+alt+any function key (f1/f2/f3/etc). Most distros use TTY1 or TTY7 for their GUI, so try ctrl+alt+f2. If it doesn’t change to a terminal screen, try another function key. From there it should prompt you to enter a username and password. Try and log in to your account. If you can, it’s probably an issue with KDE, if you can’t there’s still something wrong with how you have the drives mounted, missing files, or incorrect file permissions.

    Sorry if the formatting is a little chaotic, I added the part about checking ownership in after writing the rest


  • Docker is professional software and because of that isn’t always the most intuitive thing to use.

    The first big thing to get your head around is that there is no GUI. Everything you do to manage docker is through the command line. If you really want to, there’s some third party GUI software for managing Docker, but I haven’t used it in the 2 years I’ve been using Docker.

    Once you’ve installed docker, there’s a little bit of setup required to make it run smoothly. The Docker Docs page on Linux post-installation steps has detailed instructions on how to do that and how to run a test container



  • Going over your steps, it looks like you forgot to copy the contents of your old home directory (partition A) into the new partition on drive B before editing your fstab file. This would cause the system to boot and not find any home directory (because once you change the fstab file it only knows to look for it on drive B) and then fail to log you in.

    You also shouldn’t have to remount your home directory (partition A) before copying files over because it’s already mounted when you boot your system.

    Hope this helps! Let me know if you have any questions!









  • Disclaimer: I’m on mobile, please excuse and terrible formatting

    The issue that you’re running into is that the Python module “libevdev” isn’t installed.

    The traditional “best practice” for installing python modules is to create a python virtual environment (venv) for each project so they can have different versions of the same module. However, this will make running the script/program a little less convenient. I’ll include instructions for both, you only need to follow one.

    With a Virtual Environment

    The first thing we’ll want to do is create a virtual environment. This will let us install modules that don’t mess with the rest of the system.

    All of these commands should be run in the root folder of the application (the folder that src is inside of). Run the following command to create a folder (.venv) the virtual environment will be stored in.

    python -m venv .venv

    Next, we’ll want to activate the virtual environment. This needs to be done every time you run the application. If you’re using the bash shell the following command will active the virtual environment. (The bash shell is the default in Ubuntu. If you haven’t changed it this what you want)

    source .venv/bin/activate

    Now that we’ve created and activated a virtual environment, we can install the missing package.

    The repository you linked has a requirements.txt file we can use to install all the required modules without typing them out by hand. This can be done using pip and the ”-r” flag.

    pip install -r requirements.txt

    Now that everything is installed, you should be able to run the application as normal with:

    sudo python -m src

    If you close your terminal window, you’ll have to reactivate the virtual environment the next time you want to run the script/program. You can also write a bash script to do this for you.

    Without a Virtual Environment

    If you don’t want to setup a virtual environment, you can install the modules user wide. This will make it so the installed packages are available every time you run python. You can do this with pip as follows. Make sure to run this command in the root folder of the application (the folder src is in)

    pip install -r requirements.txt

    You should then be able to run the script/program as you did before with

    sudo python -m src


  • Please avoid Manjaro. I’ve had my Manjaro install break more than any other distro. If you want something arch based, you’re better off installing Arch from scratch, using the arch install script, or using EndeavorOS. All three of these options use the normal arch repositories which are far more stable than the Manjaro ones, and also offer much better compatibility with the AUR






  • As someone who has used both as my primary operating system the main reason I ended up on Arch is the Arch User Repository (AUR).

    The AUR allows you to run installation scripts for apps that aren’t supported by the official repositories and pretty much everything you could ever want is there.

    The other big thing I liked is the Arch Wiki documents everything really well, and I preferred the kinds of answers I found there and on the Arch forums to the Ubuntu/Mint forums.

    At the time, operating system overhead was extremely important to me and a window manager like i3 or awesome was less resource intensive than Mint’s Cinnamon Desktop Environment (DE).

    All of that being said though, because Arch doesn’t ship with a DE getting started will require a configuring a lot of things using old school text based configuration files. The Mint installed on the other hand leaves you with a very capable and functional system as soon as you finish installing it.

    If you want something that works right out of the box, I would recommend Mint. If you want a project give Arch a shot!


  • nvidia drivers on linux is troublesome. They don’t support their own proprietary drivers well and don’t share with the devs working on open source ones. As expected, you end up with two different feature incomplete drivers and it’s a huge hassle.

    iirc you should be fine with an intel or and cpu and it’s just the gpu you need to be careful with, but my experience is with an amd cpu and nvidia gpu so I may be wrong