wip

4 files changed, 332 insertions, 0 deletions

diff --git a/content/posts/2018-07-18-better-init.es.md b/content/posts/2018-07-18-better-init.es.md
new file mode 100644
index 0000000..62d3e44
--- /dev/null
+++ b/content/posts/2018-07-18-better-init.es.md
@@ -0,0 +1,128 @@
+---
+layout: post
+title: better-initramfs (Dropbear + LVM + LUKS) setup
+category: GNU/Linux
+showToc: true
+TocOpen: true
+tags:
+  - initramfs
+  - linux
+  - dropbear
+  - lvm
+  - luks
+---
+
+Desde hace años que uso better-initramfs en todos los sistemas que necesiten un
+initramfs y es que como su nombre anuncia, es mejor que todas las alternativas
+IMO (mkinit, genkernel, dracut...etc). Es rápido, tiene soporte para lvm, luks,
+dropbear! y encima es totalmente independiente del kernel!, una vez 'compilado'
+te puedes olvidar (cuidado con los 0days de Dropbear)... todo ventajas. Esta es
+mi configuración para un servidor con LVM on LUKS en un SSD.
+
+<hr>
+
+# Instalación desde git
+
+```
+cd /opt
+git clone https://bitbucket.org/piotrkarbowski/better-initramfs.git
+```
+
+La compilación la hace en un chroot por lo que hace falta hacerlo como root!
+
+```
+cd better-initramfs
+bootstrap/bootstrap-all
+make prepare
+```
+
+## Shell remota (Opcional)
+
+Antes de crear la imagen tenemos que añadir las claves públicas que tendrán
+acceso.
+
+```
+cp /rutal/a/.ssh/authorized_keys /opt/better-initramfs/sourceroot
+```
+
+# Crear e instalar la imagen
+
+```
+make image
+cp /opt/better-initramfs/output/initramfs.cpio.gz /boot
+```
+
+# Entrada de GRUB
+
+better-initramfs es muy flexible y soporta muchísimas configuraciones, en la
+[página oficial](https://bitbucket.org/piotrkarbowski/better-initramfs#rst-header-parameters)
+están explicadas al detalle todas las opciones. Es importante consultar la
+documentación oficial pues algunos parámetros pueden cambiar con el tiempo o
+dejar de existir (eg `luks_trim` ya no existe).
+
+Editamos el fichero `/etc/grub.d/40_custom` y añadimos una nueva entrada, en mi
+caso queda así:
+
+```
+#!/bin/sh exec tail -n +3 $0
+
+# This file provides an easy way to add custom menu entries. Simply type the
+
+# menu entries you want to add after this comment. Be careful not to change
+
+# the 'exec tail' line above.
+
+menuentry 'Gentoo Linux 4.17.7 (better-init)' --class gentoo --class gnu-linux
+--class gnu --class os { load_video insmod gzio insmod part_msdos insmod fat set
+root='hd2,msdos1' search --no-floppy --fs-uuid --set=root 2ACF-01EF echo
+'Loading Linux 4.17.7 ...' linux /vmlinuz-4.17.7-gentoo \
+ root=/dev/mapper/vg1-root ro lvm luks sshd\
+ binit_net_if=eth3 binit_net_addr=10.0.0.242/24\
+ binit_net_gw=10.0.0.1\
+ enc_root=UUID=ca098a60-f942-43be-9138-bcb06922211f\
+ rootfstype=ext4 echo 'Loading initial ramdisk ...' initrd /initramfs.cpio.gz }
+```
+
+_La mayoria de líneas se pueden copiar descaradamente de las entradas que genera
+GRUB automáticamente!_
+
+Básicamente las únicas dos líneas en las que estamos interesados son la del
+kernel (`linux ...`), a la que se le pasan todos los parámetros y el initrd que
+debe apuntar a la imagen creada anteriormente (aparte del título, los `echo` y
+demás pijadas).
+
+`root=` : partición con la raiz (`/`).  
+`lvm` : escanea los discos en busca de volúmenes.  
+`enc_root=UUID=...` : especifica el UUID de la partición cifrada.  
+`luks` : indica que queremos hacer `luksOpen` en `enc_root`.  
+`ro` : monta la raiz en read-only.  
+`binit_net_if` `binit_net_addr` `binit_net_gw` : interfaz, dirección y gateway
+que queremos usar.  
+`sshd` : ejecutar el servidor ssh para poder introducir la clave de forma
+remota.  
+`rootfstype` : el formato de la partición raíz.
+
+Montamos `/boot` si está en otra partición y regeneramos el `grub.cfg`.
+
+```
+mount /boot
+grub-mkconfig -o /boot/grub/grub.cfg
+```
+
+## Cambiar el orden de las entradas de GRUB (Opcional)
+
+El número delante de los ficheros en `/etc/grub.d` especifica el orden en el que
+son procesados, para que la entrada personalizada sea seleccionada por defecto,
+basta con mover el fichero `40_custom` editado anteriormente y regenerar
+`grub.cfg`.
+
+```
+mv /etc/grub.d/40_custom /etc/grub.d/05_better-initramfs
+grub-mkconfig -o /boot/grub/grub.cfg
+```
+
+---
+
+**Fuentes**:
+
+- [better-initramfs](https://bitbucket.org/piotrkarbowski/better-initramfs#rst-header-build-from-source)
diff --git a/content/posts/2018-08-01-dxvk-gentoo.md b/content/posts/2018-08-01-dxvk-gentoo.md
new file mode 100644
index 0000000..e71cac3
--- /dev/null
+++ b/content/posts/2018-08-01-dxvk-gentoo.md
@@ -0,0 +1,124 @@
+---
+layout: post
+draft: true
+title: Building DXVK's DLLs on Gentoo
+
+TocOpen: true
+ShowToc: true
+---
+
+By far the easiest way to do it is on a Debian chroot, but that ain't as fun as
+building your own toolchains and do it on Gentoo.
+
+<hr>
+
+# Dependencies
+
+According to the official documentation:
+
+- wine 3.10 or newer
+- Meson build system (at least version 0.43)
+- MinGW64 compiler and headers (requires threading support)
+- glslang front end and validator
+
+{% highlight code %}
+
+# emerge virtual/wine dev-util/meson dev-util/glslang
+
+{% endhighlight %}
+
+## MinGW64
+
+MinGW with POSIX threads is needed, problem is by default crossdev will compile
+GCC with Win32 threads.
+
+Start by creating your toolchains, tuple for x86 is `i686-w64-mingw32` and
+`x86_64-w64-mingw32` for x64.
+
+{% highlight code %}
+
+# crossdev -t i686-w64-mingw32
+
+# crossdev -t x86_64-w64-mingw32
+
+{% endhighlight %}
+
+Fix GCC by enabling POSIX threads and adding the `libraries` USE to
+`mingw64-runtime`.
+
+{% highlight code %}
+
+# mkdir /etc/portage/{env,package.env}
+
+# echo 'EXTRA_ECONF="--enable-threads=posix"' > /etc/portage/env/mingw32_posix_threads
+
+# echo -e 'cross-i686-w64-mingw32/gcc mingw32_posix_threads\ncross-x86_64-w64-mingw32/gcc mingw32_posix_threads' > /etc/portage/package.env/mingw32_posix_threads
+
+{% endhighlight %}
+
+{% highlight code %} cross-i686-w64-mingw32/mingw64-runtime libraries
+cross-x86_64-w64-mingw32/mingw64-runtime libraries {% endhighlight %}
+
+Rebuild `mingw64-runtime` and `gcc`. Order matters, `mingw64-runtime` with
+`libraries` provides `pthreads.h` and other stuff that is needed to compile GCC
+with POSIX thread model.
+
+{% highlight code %}
+
+# emerge -1 cross-i686-w64-mingw32/mingw64-runtime cross-x86_64-w64-mingw32/mingw64-runtime
+
+# emerge -1 cross-i686-w64-mingw32/gcc cross-x86_64-w64-mingw32/gcc
+
+{% endhighlight %}
+
+_Depending on the runtime version, libraries may end up in the wrong place (see
+bug #653246), if that is the case sysmlink those and then rebuild GCC._ _eg_
+{% highlight code %}
+
+# ln -s /usr/x86_64-w64-mingw32/usr/lib64/{libmangle.a,libpthread.a,libpthread.dll.a,libwinpthread.a,libwinpthread.dll.a,libwinpthread.la} /usr/x86_64-w64-mingw32/usr/lib/
+
+{% endhighlight %}
+
+Final result should be:
+
+{% highlight code %}
+
+# i686-w64-mingw32-gcc -v
+
+# x86_64-w64-mingw32-gcc -v
+
+... Thread model: posix ... {% endhighlight %}
+
+# Crosscompiling DLLs
+
+{% highlight code %}
+
+# su user
+
+$ cd $ git clone https://github.com/doitsujin/dxvk.git $ cd dxvk
+
+### 32-bit build. For 64-bit builds, replace
+
+### build-win32.txt with build-win64.txt
+
+### build.w32 with build.w64
+
+$ meson --cross-file build-win32.txt --prefix /some/install/prefix build.w32 $
+cd build.w32/ $ meson configure -Dbuildtype=release $ ninja $ ninja install
+{% endhighlight %} {% highlight code %} $ ls /some/install/prefix/bin d3d11.dll
+dxgi.dll setup_dxvk.sh {% endhighlight %}
+
+These are the toolchains I used.
+
+{% highlight code %} cross-i686-w64-mingw32/binutils-2.30-r3
+cross-i686-w64-mingw32/gcc-7.3.0-r3 cross-i686-w64-mingw32/mingw64-runtime-5.0.4
+
+cross-x86_64-w64-mingw32/binutils-2.30-r3 cross-x86_64-w64-mingw32/gcc-7.3.0-r3
+
+### symlinks from ...lib64/ -> ...lib/ required! see bug #653246
+
+cross-x86_64-w64-mingw32/mingw64-runtime-5.0.4 {% endhighlight %}
+
+---
+
+#### [Original in spanish](/gnu/linux/2018/08/01/dxvk-gentoo/)
diff --git a/content/posts/2019-02-02-xdg-runtime-dir.md b/content/posts/2019-02-02-xdg-runtime-dir.md
new file mode 100644
index 0000000..1e5fac4
--- /dev/null
+++ b/content/posts/2019-02-02-xdg-runtime-dir.md
@@ -0,0 +1,28 @@
+---
+layout: post
+title: XDG_RUNTIME_DIR on non-systemd systems
+category: GNU/Linux
+tags:
+  - systemd
+  - gentoo
+---
+
+On systemd/ConsoleKit systems this variable is set when the user logs in, if
+neither is used and you need `XDG_RUNTIME_DIR` for some reason (eg Flatpak), it
+can be easily set adding some lines to your `.bash_profile`:
+
+```bash
+if test -z "${XDG_RUNTIME_DIR}"; then
+    export XDG_RUNTIME_DIR=/tmp/${UID}-runtime-dir
+    if ! test -d "${XDG_RUNTIME_DIR}"; then
+        mkdir "${XDG_RUNTIME_DIR}"
+        chmod 0700 "${XDG_RUNTIME_DIR}"
+    fi
+fi
+```
+
+---
+
+**Sources**:
+
+- [Weston](https://wiki.gentoo.org/wiki/Weston)
diff --git a/content/posts/2021-02-03-gentoo-no-desktop-lag.md b/content/posts/2021-02-03-gentoo-no-desktop-lag.md
new file mode 100644
index 0000000..966419b
--- /dev/null
+++ b/content/posts/2021-02-03-gentoo-no-desktop-lag.md
@@ -0,0 +1,52 @@
+---
+layout: post
+title: Say goodbye to desktop lag while compiling your @world
+category: GNU/Linux
+tags:
+  - gentoo
+  - systemd
+---
+
+1. Start by creating a new systemd slice `/etc/systemd/system/portage.slice`:
+
+   ```
+   [Install]
+   WantedBy=slices.target
+
+   [Slice]
+   CPUShares=256
+   ```
+
+1. Enable and start the unit you just created:
+
+   ```
+   systemctl enable --now portage.slice
+   ```
+
+   CPUShares option defaults to 1024, `systemd` will create a user slice for
+   each user with an active session, and all processes that user run will be
+   assigned to that slice, anything that a user may run will receive 4 times the
+   CPU time of processes assigned to the portage slice.
+
+   ```
+   ➜  ~ cat /sys/fs/cgroup/cpu,cpuacct/user.slice/cpu.shares
+   1024
+   ```
+
+1. Repurpose `PORTAGE_IONICE_COMMAND` variable. This is one of those awesome
+   variables you can set in your `make.conf` to alter how you build stuff. It
+   should be a command string for portage to call to modify its own priority
+   with a `\${PID}` placeholder that will be substituted with a `PID`. Maybe it
+   was created with `ionice` in mind, but we can abuse that placeholder to write
+   pids to the `cgroup.procs` file in the portage slice.
+
+   Add the following line to your `/etc/portage/make.conf`:
+
+   ```
+   PORTAGE_IONICE_COMMAND="sh -c \"echo \${PID} > /sys/fs/cgroup/systemd/portage.slice/cgroup.procs\""
+   ```
+
+   The `cgroup.procs` file is present in every cgroup and contains a list of
+   processes that are members of that particular cgroup. Writing a PID to this
+   file will move all threads in that process at once to the cgroup. And that,
+   is awesome :D