Admin? Anyone? Let's say Anyhelp is appreciated!
A quick tip for GNU Nano – the text editor. Ever receiving the terminal error when using nano?
[root@srv ~]# nano Error opening terminal: unknown. [root@srv ~]#
Under chroot or container (like docker) environment try exporting the TERM environment:
export TERM=linux
And then execute nano the chances are you will enter nano normally and do your work (faster than vim 🙂 )?
You may use it without exporting to your shell, but just the for the nano:
TERM=linux nano
What a miss here in our docker Cobbler instance! When trying to import a new distro in Cobbler the import finished with failed task and multiple errors of:
running: /usr/bin/file /var/www/cobbler/ks_mirror/ubuntu-18.04.3-server-amd64-x86_64/dists/bionic/Release.gpg received on stdout: received on stderr: /bin/sh: /usr/bin/file: No such file or directory running: /usr/bin/file /var/www/cobbler/ks_mirror/ubuntu-18.04.3-server-amd64-x86_64/dists/bionic/main/binary-i386/Release received on stdout: received on stderr: /bin/sh: /usr/bin/file: No such file or directory
The “file”? Apparently, the Linux file command is missing and it is just possible because it is a docker container with the minimum installation of packages and dependencies.
Without the “file” command import will fail with “No signature matched” even you have synced with the latest signature just before the execution of the import command.
Install the package “file” in your server.
CentOS 7/Fedora:
yum install -y file
Ubuntu
apt install -y file
When installing cobbler (in our case 2.6.11, but it might happen with other versions) from source, because they do not offer binary packages anymore, the web showed this error:
[Tue Oct 08 07:41:00.680646 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] mod_wsgi (pid=8770): Exception occurred processing WSGI script '/usr/local/share/cobbler/web/cobbler.wsgi'. ..... ..... [Tue Oct 08 07:41:00.687544 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] ImproperlyConfigured: The SECRET_KEY setting must not be empty.
The solution is simply to add value to the variable SECRET_KEY in file “/usr/local/share/cobbler/web/settings.py” (this file might be in /usr/share/cobbler/web/settings.py)
root@srv:~# grep -n SECRET_KEY /usr/local/share/cobbler/web/settings.py 39:SECRET_KEY = ''
The 39th line put a randomly generated text. You may use openssl to generate the random text like:
root@srv:~# openssl rand -base64 32 NVb09/5TWmCcqfDBLsvyCppza9lJ5Eyb0HWW4HTlSfo=
Edit the cobbler web setting file and put the string there:
root@srv:~# grep SECRET_KEY /usr/local/share/cobbler/web/settings.py SECRET_KEY = 'NVb09/5TWmCcqfDBLsvyCppza9lJ5Eyb0HWW4HTlSfo='
The error could be seen in Cobbler web installed in Ubuntu 16 when installing cobbler 2.6.11.
[Tue Oct 08 07:41:00.680646 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] mod_wsgi (pid=8770): Exception occurred processing WSGI script '/usr/local/share/cobbler/web/cobbler.wsgi'.
[Tue Oct 08 07:41:00.680724 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] Traceback (most recent call last):
[Tue Oct 08 07:41:00.680764 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] File "/usr/local/share/cobbler/web/cobbler.wsgi", line 27, in application
[Tue Oct 08 07:41:00.681890 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] return _application(environ, start_response)
[Tue Oct 08 07:41:00.682025 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] File "/usr/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 170, in __call__
[Tue Oct 08 07:41:00.683222 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] self.load_middleware()
[Tue Oct 08 07:41:00.683380 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 49, in load_middleware
[Tue Oct 08 07:41:00.685006 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] for middleware_path in settings.MIDDLEWARE_CLASSES:
[Tue Oct 08 07:41:00.685168 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 48, in __getattr__
[Tue Oct 08 07:41:00.686783 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] self._setup(name)
[Tue Oct 08 07:41:00.687047 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 44, in _setup
[Tue Oct 08 07:41:00.687111 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] self._wrapped = Settings(settings_module)
[Tue Oct 08 07:41:00.687133 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 113, in __init__
[Tue Oct 08 07:41:00.687472 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] raise ImproperlyConfigured("The SECRET_KEY setting must not be empty.")
[Tue Oct 08 07:41:00.687544 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] ImproperlyConfigured: The SECRET_KEY setting must not be empty.
This article is for those of you who do not want to install a whole new operating system only to discover some technical details about the default installation like disk layout, packages included, software versions and so on. Here we are going to review in several sections what is like to have a default installation of CentOS 8.0.
Despite the kernel is 4.18 it detects successfully the new RYZEN/Threadripper AMD and the system is stable (we booted in UEFI mode).
The CentOS 8.0 (8.0.1950) you can have
Note: Not all of the above software comes installed by default.
The installation procedure you can find here – How to do a network installation of CentOS 8 (8.0.1950) – minimal server installation Minimal install with “Standard” Addons selected.
Installed packages are 547 occupying 1.8G space:.
[root@srv ~]# dnf list installed|wc -l 547 [root@srv ~]# df -h / Filesystem Size Used Avail Use% Mounted on /dev/mapper/cl_srv-root 50G 1.8G 49G 4% /
Note: if you do not select “Standard Addon” the installation occupies less space – 1.6Gbytes and installs only 397 packages.
Keep on reading!
When upgrading to 17.1 profile you need to perform additional steps to get to a healthy Gentoo portage system using profile 17.1.
Here what we stumbled when we tried to upgrade from 13 to 17.1:
>>> Emerging (1 of 3) dev-libs/elfutils-0.177::gentoo * Fetching files in the background. * To view fetch progress, run in another terminal: * tail -f /var/log/emerge-fetch.log * elfutils-0.177.tar.bz2 BLAKE2B SHA512 size ;-) ... [ ok ] * Please follow the instructions in the news item: * 2019-06-05-amd64-17-1-profiles-are-now-stable * or choose the 17.0 profile. * ERROR: dev-libs/elfutils-0.177::gentoo failed (setup phase): * ERROR: 17.1 migration has not been performed!! * * Call stack: * ebuild.sh, line 591: Called __source_all_bashrcs * ebuild.sh, line 410: Called __try_source '/usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc' * ebuild.sh, line 467: Called __qa_source '/usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc' * ebuild.sh, line 112: Called source '/usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc' * profile.bashrc, line 6: Called die * The specific snippet of code: * die "ERROR: 17.1 migration has not been performed!!" * * If you need support, post the output of `emerge --info '=dev-libs/elfutils-0.177::gentoo'`, * the complete build log and the output of `emerge -pqv '=dev-libs/elfutils-0.177::gentoo'`. * The complete build log is located at '/var/tmp/portage/dev-libs/elfutils-0.177/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/elfutils-0.177/temp/die.env'. * Working directory: '/var/tmp/portage/dev-libs/elfutils-0.177/homedir' * S: '/var/tmp/portage/dev-libs/elfutils-0.177/work/elfutils-0.177'
As you can see there is news, which consists of 12 steps to perform a successful upgrade to profile 17.1.
You can read the news with (the news output is included at the end of this article, just for completeness):
eselect news read 28
Specific note for our upgrade – in fact, our Gentoo installation was a chroot and it had not been updated for three years. The profile was 13.0 and portage supported only EAPI 5, which is a real problem. The new portage tree (we installed the latest) has no profile 13.0 and our emerge was half broken. We have preliminary steps described in Failed to install sys-apps/portage – Called pkg_preinst – portage._compat_upgrade.default_locations
Because we upgrade from 13.0 to 17.1, first, we need to perform the 17.0 upgrade (check the original steps here – https://gentoo.org/support/news-items/2017-11-30-new-17-profiles.html)
srv ~ # eselect profile set default/linux/amd64/17.0
You won’t be able to build any GNU GCC and you cannot continue with the next step.
Our current GNU GCC is really old – 4.9.3. The latest version is gcc-9.2.0-r1 and we are going to use it.
Keep on reading!
Cobbler web (probably not the latest) uses Django and since version 1.5 (IIUC) if your IP is not in an allowed host directive – ALLOWED_HOSTS you will get 400 and the following apache errors:
[Mon Jan 14 13:44:27.805290 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] mod_wsgi (pid=5897): Exception occurred processing WSGI script '/usr/share/cobbler/web/cobbler.wsgi'. ..... ..... [Mon Jan 14 13:44:27.805743 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] DisallowedHost: Invalid HTTP_HOST header: '192.168.0.25'. You may need to add u'192.168.0.25' to ALLOWED_HOSTS.
The solution is simple enough – add your host in the ALLOWED_HOSTS.
But where? In which cobbler configuration file?
Find the cobbler web setting file and add a line for ALLOWED_HOSTS.
In Ubuntu the file is “/usr/share/cobbler/web/settings.py” and add the following:
DEBUG = True
TEMPLATE_DEBUG = DEBUG
ALLOWED_HOSTS = '*'
ADMINS = (
# ('Your Name', 'your_email@domain.com'),
)
This will instruct Django to accept requests from all IPs. Now Cobbler web will work.
The error could be seen in Cobbler web installed in Ubuntu 16 with the latest package cobbler-web 2.4.1-0ubuntu2.
[Mon Jan 14 13:44:27.805290 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] mod_wsgi (pid=5897): Exception occurred processing WSGI script '/usr/share/cobbler/web/cobbler.wsgi'. [Mon Jan 14 13:44:27.805360 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] Traceback (most recent call last): [Mon Jan 14 13:44:27.805381 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 189, in __call__ [Mon Jan 14 13:44:27.805420 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] response = self.get_response(request) [Mon Jan 14 13:44:27.805429 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 207, in get_response [Mon Jan 14 13:44:27.805442 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] return debug.technical_500_response(request, *sys.exc_info(), status_code=400) [Mon Jan 14 13:44:27.805449 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/views/debug.py", line 97, in technical_500_response [Mon Jan 14 13:44:27.805463 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] html = reporter.get_traceback_html() [Mon Jan 14 13:44:27.805470 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/views/debug.py", line 384, in get_traceback_html [Mon Jan 14 13:44:27.805480 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] return t.render(c) [Mon Jan 14 13:44:27.805487 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 210, in render [Mon Jan 14 13:44:27.805499 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] return self._render(context) [Mon Jan 14 13:44:27.805505 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 202, in _render [Mon Jan 14 13:44:27.805516 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] return self.nodelist.render(context) [Mon Jan 14 13:44:27.805523 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 905, in render [Mon Jan 14 13:44:27.805533 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] bit = self.render_node(node, context) [Mon Jan 14 13:44:27.805551 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/template/debug.py", line 79, in render_node [Mon Jan 14 13:44:27.805563 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] return node.render(context) [Mon Jan 14 13:44:27.805569 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/template/defaulttags.py", line 329, in render [Mon Jan 14 13:44:27.805582 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] return nodelist.render(context) [Mon Jan 14 13:44:27.805589 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 905, in render [Mon Jan 14 13:44:27.805602 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] bit = self.render_node(node, context) [Mon Jan 14 13:44:27.805609 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/template/debug.py", line 79, in render_node [Mon Jan 14 13:44:27.805621 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] return node.render(context) [Mon Jan 14 13:44:27.805627 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/template/debug.py", line 89, in render [Mon Jan 14 13:44:27.805639 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] output = self.filter_expression.resolve(context) [Mon Jan 14 13:44:27.805647 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 648, in resolve [Mon Jan 14 13:44:27.805657 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] obj = self.var.resolve(context) [Mon Jan 14 13:44:27.805663 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 789, in resolve [Mon Jan 14 13:44:27.805673 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] value = self._resolve_lookup(context) [Mon Jan 14 13:44:27.805679 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 849, in _resolve_lookup [Mon Jan 14 13:44:27.805689 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] current = current() [Mon Jan 14 13:44:27.805696 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/http/request.py", line 152, in build_absolute_uri [Mon Jan 14 13:44:27.805708 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] host=self.get_host(), [Mon Jan 14 13:44:27.805714 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] File "/usr/lib/python2.7/dist-packages/django/http/request.py", line 102, in get_host [Mon Jan 14 13:44:27.805725 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] raise DisallowedHost(msg) [Mon Jan 14 13:44:27.805743 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] DisallowedHost: Invalid HTTP_HOST header: '192.168.0.25'. You may need to add u'192.168.0.25' to ALLOWED_HOSTS.
Minimal net install is useful when a dedicated server is installed from a IPMI KVM or Dell iDRAC, HP iLO, IBM IMM or where the initial client side download of files need to be minimal.
For amd64 CentOS 8 BaseOS the net install bootable media is located here (now the current latest release is 8.0.1950, but you can check the last directory with 8.
http://mirror.leaseweb.com/centos/8/isos/x86_64/CentOS-8-x86_64-1905-boot.iso
Note there is no minimal CD for offline installation anymore. Boot CD is to just boot and make “netinstall” installation and a big fat DVD of 6.6Gbytes to install offline.
Software details of CentOS 8 minimal install could be found here – Technical details of a default CentOS 8.0.1950 minimal installation
Download it and put it on a cd or usb, the boot from it and follow the steps bellow:
You can try F11 on most servers to have the boot menu. Here we use DEL to enter the UEFI BIOS.
Keep on reading!
Recently there was a problem with one compute node servers, which Gentoo (in fact, the chroot environment had not been updated for 3 years) could not emerge the new portage because it kept failing in the pkg_preinst with:
srv ~ # USE="-rsync-verify" emerge -va '=sys-apps/portage-2.3.76::gentoo'
.....
.....
>>> Installing (1 of 1) sys-apps/portage-2.3.76::gentoo
* checking 1999 files for package collisions
1000 files checked ...
^[[B>>> Merging sys-apps/portage-2.3.76 to /
/usr/bin/python2.7: No module named _compat_upgrade
* ERROR: sys-apps/portage-2.3.76::gentoo failed (preinst phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 133: Called pkg_preinst
* environment, line 3238: Called die
* The specific snippet of code:
* env -u DISTDIR -u PORTAGE_OVERRIDE_EPREFIX -u PORTAGE_REPOSITORIES -u PORTDIR -u PORTDIR_OVERLAY PYTHONPATH="${D%/}${PYTHON_SITEDIR}${PYTHONPATH:+:${PYTHONPATH}}" "${PYTHON}" -m portage._compat_upgrade.default_locations || die;
*
* If you need support, post the output of `emerge --info '=sys-apps/portage-2.3.76::gentoo'`,
* the complete build log and the output of `emerge -pqv '=sys-apps/portage-2.3.76::gentoo'`.
* The complete build log is located at '/var/tmp/portage/sys-apps/portage-2.3.76/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/sys-apps/portage-2.3.76/temp/environment'.
* Working directory: '/var/tmp/portage/._portage_reinstall_.RKkxLW/pym'
* S: '/var/tmp/portage/sys-apps/portage-2.3.76/work/portage-2.3.76'
!!! FAILED preinst: 1
>>> Failed to install sys-apps/portage-2.3.76, Log file:
>>> '/var/tmp/portage/sys-apps/portage-2.3.76/temp/build.log'
Note this is the installation phase, where everything from the build process passes smoothly, but it fails to install it with some vague error of a dying line with a couple of python and portage environments. The problem is the current portage does not support EAPI 6 and 7 and some packages were unable to be installed!
And we fixed the issue by just using the method described in our previous article – Fix your broken or old portage in Gentoo, fix the emerge command
Cloning a new portage software and using it to emerge (install) a newer (or reinstall the current) portage in the system to fix the system’s portage and the emerge command:
cd /root git clone https://anongit.gentoo.org/git/proj/portage.git /root/portage/bin/emerge --sync eselect profile set default/linux/amd64/17.1 /root/portage/bin/emerge -v portage
Now the latest and stable Gentoo profile is 17.1, so we set it to be sure we use it (in future this may change).
Keep on reading!
Using Gentoo for servers and chroots it might happen to deal with old and not regularly updated Gentoo environment, which in some cases is completely non-updatable using the regular process with emerge command. And no emerge means no installs from the Gentoo packaging system. Or you maybe have a broken portage after failed update with missing emerge command or missing or broken portage modules
In general, this article is for those, who cannot update their “sys-apps/portage” or even the emerge command exits with errors and is of no use.
In cases such as:
A real world errors are included at the bottom for each case above.
You need just a working python 2.7.x and git to clone “https://anongit.gentoo.org/git/proj/portage.git” or at least some tool to download the portage package.
Our example is to repair a completely broken portage with error:
srv ~ # emerge -va portage
Traceback (most recent call last):
File "/usr/lib/python-exec/python2.7/emerge", line 42, in <module>
import portage
ImportError: No module named portage
If you do not have a git client you can always check the URL in the sys-app/portage ebuild and download the URL. Still, if you cannot find the tarball’s URL, you can just simply get a mirror such as https://mirror.leaseweb.com/gentoo/distfiles, wait for the loading of the page (12Mbytes, it’s huge, all Gentoo tarball files’ names are here) and grep in it by the name “portage”. Or you can check here https://dev.gentoo.org/~zmedico/portage/archives/. Download the latest tarball and unpack it in the /root directory.
Using git is the easiest method, but is the same with downloading and unpacking the tarball in the “/root”.
srv root # git clone https://anongit.gentoo.org/git/proj/portage.git Cloning into 'portage'... remote: Enumerating objects: 151654, done. remote: Counting objects: 100% (151654/151654), done. remote: Compressing objects: 100% (39915/39915), done. remote: Total 151654 (delta 112542), reused 149864 (delta 111349) Receiving objects: 100% (151654/151654), 22.38 MiB | 550.00 KiB/s, done. Resolving deltas: 100% (112542/112542), done. srv root # cd portage/ srv portage # ls -al total 232 drwxr-xr-x. 11 root root 4096 Oct 6 04:52 . drwx------. 4 root root 4096 Oct 6 04:51 .. drwxr-xr-x. 6 root root 4096 Oct 6 04:52 bin drwxr-xr-x. 5 root root 4096 Oct 6 04:52 cnf -rw-r--r--. 1 root root 1840 Oct 6 04:52 COPYING -rw-r--r--. 1 root root 6646 Oct 6 04:52 DEVELOPING drwxr-xr-x. 5 root root 4096 Oct 6 04:52 doc -rw-r--r--. 1 root root 200 Oct 6 04:52 .editorconfig drwxr-xr-x. 7 root root 4096 Oct 6 04:52 .git -rw-r--r--. 1 root root 80 Oct 6 04:52 .gitignore drwxr-xr-x. 4 root root 4096 Oct 6 04:52 lib -rw-r--r--. 1 root root 18092 Oct 6 04:52 LICENSE -rwxr-xr-x. 1 root root 1272 Oct 6 04:52 make.conf.example-repatch.sh drwxr-xr-x. 3 root root 4096 Oct 6 04:52 man -rw-r--r--. 1 root root 290 Oct 6 04:52 MANIFEST.in drwxr-xr-x. 2 root root 4096 Oct 6 04:52 misc -rw-r--r--. 1 root root 17845 Oct 6 04:52 NEWS -rw-r--r--. 1 root root 0 Oct 6 04:52 .portage_not_installed -rw-r--r--. 1 root root 2246 Oct 6 04:52 README -rw-r--r--. 1 root root 68122 Oct 6 04:52 RELEASE-NOTES drwxr-xr-x. 6 root root 4096 Oct 6 04:52 repoman -rwxr-xr-x. 1 root root 4889 Oct 6 04:52 runtests -rwxr-xr-x. 1 root root 19743 Oct 6 04:52 setup.py drwxr-xr-x. 2 root root 4096 Oct 6 04:52 src -rwxr-xr-x. 1 root root 81 Oct 6 04:52 tabcheck.py -rw-r--r--. 1 root root 1864 Oct 6 04:52 TEST-NOTES -rw-r--r--. 1 root root 571 Oct 6 04:52 testpath -rw-r--r--. 1 root root 348 Oct 6 04:52 tox.ini -rw-r--r--. 1 root root 584 Oct 6 04:52 .travis.yml
This is the latest portage with working emerge command in the bin sub-directory.
Keep on reading!
Inspired by our article – SSD cache device to a hard disk drive using LVM, which uses SSD driver as a cache device to a single hard drive, we decided to make a new article, but this time using two hard drives in raid setup (in our case RAID1 for redundancy) and a single NVME SSD drive.
The goal:
Caching RAID1 consisting of two 8T hard drive with a single 1T NVME SSD drive. Caching reads and writes, i.e. the write-back is enabled.
Our setup: