>wsl -l
Windows Subsystem for Linux Distributions:
Ubuntu-18.04 (Default)
Ubuntu
I made the mistake of setting up everything in the Ubuntu-18.04 version, which is locked to that specific version and doesn't allow dist upgrades (Please prove me wrong). This includes shell customizations, symlinks etc.
I would however like to upgrade Ubuntu every once in a while. What I do not want to do is manually find all the configuration files and copy them to the new distribution.
The Ubuntu distribution is the one from the Windows store; fresh clean with no modifications.
How do I get my data from the old distribution into the fresh Ubuntu store distribution? Or is there a way to upgrade the locked Ubuntu-18.04 distribution (also from the Windows store)?
I know of wsl --export and wsl --import, but as far as I can tell these keep the distribution (with in this case the lack of upgrades) and just place a copy of that distribution into another folder. Which does not solve the dist upgrade problem.
I ended up using the free, legacy version of Aptik (I couldn't get the GTK version to launch). Even though it's no longer maintained, it's still working perfectly well, and only took me a single command to export everything and another single command to import everything again.
Related
I have some problems trying to test "needs-restarting -r ; echo $?" inside a RedHat distribution. The command works for cases where a reboot is not required, but I have not been able to voluntarily generate the need to reboot in the operating system, which has made it impossible for me to know if the response to the command works. That is to say the output in 1 of the needs-restarting. Do you know of any way to generate the need to reboot in a controlled manner in RedHat?
You can find which packages require a system reboot after the update to Redhat KB. If you can downgrade one of these packages, you can generate reboot required state. But this is not recommended in production systems. glibc and kernel downgrades can cause problems. You can try it at new installed Rhel server after "yum update".
I need to install SUMO 0.30.0 to be used with the VEINS_INET subproject in veins 4.6. I have tried following the instructions here and suggestions from forums but haven't had any luck being able to install sumo. I run ./configure (trying various tool/library options) then run sudo make but all I get is target marouter failed or nothing to be done for 'install-exec-am' 'install-data-am'.
Does anyone know how to install sumo-0.30.0 from source and/or make the veins_inet subproject work with the latest version of sumo-0.32.0?
Don't run sudo make.
Don't run sudo make.
Your problem is probably related to a dependency/packaging change in 16.04, which is explicitly pointed out in the veins tutorial:
Note that Ubuntu 16.04 no longer includes libproj0; this can be worked around by temporarily adding the packet repository of, e.g., Ubuntu Vivid when installing this package.
Short answer: Unfortunately this means that long-term, you're going to either have to package SUMO yourself, use the versions someone else compiled (see this launchpad for example) or rely on an old version.
Long answer:
In general, I would recommend building SUMO from source by building its' dependencies from source, since I've encountered this problem on various distributions. In particular, the fox, proj and gdal libraries tend to be packaged in different versions, and along with changes in the SUMO source code. I currently use this script (with the package versions downloaded) to compile SUMO -- but this is for 0.30.0, and it breaks if any of the referenced source packages are moved (which happens quite often). My general recommendation would be to either use a completely isolated version of SUMO (i.e., compiling by hand as much as possible) or relying on a pre-packaged version (see above), as long as that version is recent enough to work with VEINS.
I've had as few issues trying to upgrade postgresql-server. I've reverted back to the older version now (9.0.3) and the service is running and accessible via pgadmin/other gui tools.
However, I can't access it via the psql command (as user postgres). This may be possibly because the psql binary seems to be missing. I feel this may have happened when I uninstalled a version of postgres that I had intended to revert to.
I can't reinstall version 9.0.3 because the repo is no longer valid.
Is there any way I can install only the psql binary file and nothing else. I was considering copying the psql binary file from another server, although because the other servers have different versions of postgresql, I'm not sure if this is a good idea (?)
I think psql binaries didn't disapear from your system.
It's just that you had symbolic links from /usr/bin to your 9.0.3 binaries.
When you installed a newer version, this links where replaced to point to the new version and when you uninstalled it, they were dropped.
Try locate to find your binaries. Then you would be able to recreate your symbolic links in /usr/bin.
If you want to try 9.0.3 - you can always build it from source:
https://www.postgresql.org/ftp/source/v9.0.3/
But many distros package pqsl-client seperate from the server and you can use a newer version of psql instead (or at least try).
There are also archives of almost any distro out there and you could fetch that single rpm/deb packge from there.
This is more of a general question about workflow than perhaps a detailed bug report. This has happened to me three times: I download Anaconda, work with it beautifully, perhaps installing one or two additional packages, but mostly working with Jupyter and Scipy/Numpy/Matplotlib. Then one day conda updates itself to next release (4.0 -> 4.1, or 4.0 ->4.2 depending on the machine) and all goes suddenly wrong. Should I refrain from using conda update and reinstall Anaconda from scratch? Is this a known issue? Is there another procedure or routine I should use, such as updating every few weeks?
It may be that certain other packages(dependencies) need to be updated as well.
conda update conda
conda update anaconda
You can also prevent conda from automatically updating by adding the following to your .condarc file(should be where you installed Anaconda or your user directory and it may be hidden)
auto_update_conda: False
I installed virtualenv + virtualenvwrapper via virtualenv-burrito. However, it seems to be giving me problems now in uninstalling packages from my virtualenvs (case in point, distribute).
It seems that the distribute used by my virtualenvs is the one at /home/skrd/.venvburrito. If, inside a virtualenv, I try to upgrade distribute, it installs to /home/skrd/.virtualenvs but the virtualenv itself is still using the one at /home/skrd/.venvburrito. With that, the packages needing an updated distribute still won't work.
See,
(test)$ $ pip uninstall distribute
Not uninstalling distribute at /home/skrd/.venvburrito/lib/python/distribute-0.6.27-py2.7.egg, outside environment /home/skrd/.virtualenvs/test
I've tried renaming the .venvburrito directory (equivalent to deleting it, but with back-up) but that breaks my virtualenvs. How do I uninstall packages now?
I still don't understand what happened here but I just had the idea to check what's installed for my system's Python outside virtualenv. There I saw distribute, with a similar version to the one that's giving me problems inside a virtualenv.
I upgraded the non-virtualenv installation of distribute and, next time I checked in my virtualenv, the distribute installation has also upgraded.
(So, yes, I'm aware that my question's original intent is to remove distribute. But that was just an intermediary step to updating it---the update was unable to proceed since it can't remove the distribute currently installed. So, there, problem solved.)