[gelöst]: archlinux kernel panic – failed to execute /init

Aus gegebenem Anlass gibt es heute diesen Artikel: Nach dem Upgrade auf die Linux-Kernel 4.7.0-1 funktionierte das Archlinux nicht mehr.

kernel panic: failed to execute /init (error -2)

Na dann, auf zum fröhlichen Reparieren. Und so bin ich vorgegangen:

Archlinux Image herunterladen: https://www.archlinux.org/download/
USB-Stick mit anderem Linux vorbereiten:

# Device des USB-Sticks herausfinden
$ sudo blkid
# oder auch falls nicht eindeutig erkennbar
# hier die lsblk-Ausgabe von eines Sticks mit altem archlinux-image
$ sudo lsblk -o NAME,MAJ:MIN,RM,SIZE,RO,TYPE,MOUNTPOINT,UUID,LABEL
sdl 8:176 1 3,8G 0 disk 2015-12-01-16-59-37-00 ARCH_201512
├─sdl1 8:177 1 663M 0 part /run/media/tobi/ARCH_201512 2015-12-01-16-59-37-00 ARCH_201512
└─sdl2 8:178 1 31M 0 part 1B66-88FC ARCHISO_EFI
$ sudo gdisk /dev/sdl
# drücke 3 o w mit jeweiliger Bestätigung: ACHTUNG ALLE DATEN auf /dev/sdl werden gelöscht
$ cd Downloads
$ sudo dd if=archlinux-2016.08.01-dual.iso of=/dev/sdl

Boote archlinux-image vom USB-Stick, dann folgende Befehle eingeben:

$ loadkeys de
$ blkid
...
/dev/sdf1: UUID="F8DC-XYZZ" TYPE="vfat" PARTLABEL="EFI System" PARTUUID="12308321-a1d1-4a2c-a652-feb4da1xyzyx"
/dev/sdf2: LABEL="boot" UUID="123450fd-5ff6-4361-a111-57d08f839123" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="12345863-d0c5-4fcf-9b0e-685ab26xyzxyy"
/dev/sdf3: LABEL="archroot" UUID="1234571c-6894-4dd2-b0e8-26ff3e4b9123" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="123456ed-4d5c-4a62-a4fc-fa3e769xyxyx"
$ mount /dev/sdf3 /mnt
$ mount /dev/sdf2 /mnt/boot
$ mount /dev/sdf1 /mnt/boot/efi
$ arch-chroot /mnt /bin/bash
$ export LANG=de_DE.UTF-8
$ pacman -S filesystem
$ mkinitcpio -p linux
$ grub-mkconfig -o /boot/grub/grub.cfg
$ exit
$ umount -R /mnt
$ reboot

Yeah, das Arch funktioniert wieder!

letsencrypt mit webroot-plugin in apache integrieren

Der letsencrypt-Client bietet verschiedene Wege, um den Server zu authentifizieren. Einer von denen funktioniert über das webroot-plugin. Hierbei wird in einem festgelegten Verzeichnis des clientseitigen Servers zum Authentifizerungszeitpunkt ein Schlüssel abgelegt, der vom Letsencrypt-Server abgerufen wird. Somit kann letsencrypt den Server klar als den zu zertifizierenden Hostnamen identifizieren.

Für den Server namens myserver.mydomain.tdl liegt dieses Verzeichnis liegt unter: 

http://myserver.mydomain.tld/.well-known/acme-challenge

Man kann das Verzeichnis einfach im jeweiligen Webroot anlegen oder verknüpfen. Da aber /.well-known z.B. auch von owncloud explizit für Webdav benutzt wird, existieren möglicherweise schon rewrites in der Apache-Konfiguration. Diese können uns dazwischen kommen, sodass letsencrypt-Authentifizierung fehlschlägt.

Um mir die Administration möglichst zu vereinfachen, habe ich mich entschieden ein kleine Apache-Makro auf zusetzten, das einen Alias-Pfad für

/.well-known/acme-challenge

 verknüpft.

Apache-Makro schreiben (siehe auch Apache-Wiki zu mod_macro):

<Macro letsencrypt $certhostname>
    Alias /.well-known/acme-challenge /var/cache/letsencrypt/$certhostname/.well-known/acme-challenge
    <Directory "/var/cache/letsencrypt/$certhostname/.well-known/acme-challenge">
        AllowOverride All
        Options FollowSymlinks
        Satisfy Any
        Require all granted
    </Directory>
    #letsencrypt
    SSLCertificateFile    "/etc/letsencrypt/live/$certhostname/fullchain.pem"
    SSLCertificateKeyFile "/etc/letsencrypt/live/$certhostname/privkey.pem"
</Macro>

Apache-Module für Makros aktivieren in der Datei 

/etc/httpd/conf/httpd.conf
LoadModule macro_module modules/mod_macro.so

oberhalb der Vhosts

#Makros
Include conf/extra/httpd-macro-letsencrypt.conf

Weiterlesen

Raspberry Pi Hardware random number generator

Der Raspberry Pi 2 hat einen Hardware-Generator für Zufallszahlen. Hierfür ist auch ein Modul geladen:

[tobi@raspbpi2 ~]$ sudo lsmod
Module                  Size  Used by
fuse                   82003  3
cfg80211              476512  0
evdev                  10180  2
joydev                  9308  0
hid_logitech_hidpp      9292  0
8192cu                497157  0
hid_logitech_dj        10992  0
bcm2835_gpiomem         3522  0
bcm2835_rng             2031  0
uio_pdrv_genirq         3343  0
uio                     9033  1 uio_pdrv_genirq
sch_fq_codel            7328  6
snd_bcm2835            21874  1
snd_pcm                86717  1 snd_bcm2835
snd_timer              21835  1 snd_pcm
snd                    62709  5 snd_bcm2835,snd_timer,snd_pcm
bcm2708_rng             1171  0
rng_core                8022  3 bcm2835_rng,bcm2708_rng
ip_tables              12167  0
x_tables               16543  1 ip_tables
ipv6                  356894  62

Um das Modul bcm2835_rng zu nutzen, müssen zuerst die rng-tools installiert sein:

sudo pacman -S rng-tools

Dann testen wir mal die vorhandene Entropie mit haveged (Standard):

cat /proc/sys/kernel/random/entropy_avail
1224

Umstellen auf rngd:

sudo sh -c "echo 'RNGD_OPTS=\"-o /dev/random -r /dev/hwrng\"' > /etc/conf.d/rngd"
cat /etc/conf.d/rngd
sudo systemctl disable haveged
sudo systemctl stop haveged
sudo systemctl enable rngd
sudo systemctl start rngd

Entropie mit rngd testen:

cat /proc/sys/kernel/random/entropy_avail
3089

Hat wohl geklappt 🙂

[gelöst]: kodi crash archlinux armv7h kodi-rbp 15.2-1 raspberry pi 2

Ein Systemupdate von Arch vor ein paar Tagen führte auf meinem Raspberry Pi 2 dazu, dass kodi 15.2-1 mit folgendem Absturz seinen Dienst versagte:

############## Kodi CRASH LOG ###############

################ SYSTEM INFO ################
 Date: Do 17. Dez 18:54:37 CET 2015
 Kodi Options: 
 Arch: armv7l
 Kernel: Linux 4.1.15-1-ARCH #1 SMP Tue Dec 15 18:39:32 MST 2015
 Release: Arch Linux ARM
############## END SYSTEM INFO ##############

############### STACK TRACE #################
=====>  Core file: /home/tobi/core (2015-12-17 18:54:39.798322654 +0100)
        =========================================
[New LWP 344]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/lib/kodi/kodi.bin'.
Program terminated with signal SIGBUS, Bus error.
#0  0x75deb49c in __gnu_cxx::__exchange_and_add (__val=-1, __mem=0x6c6d782a) at /build/gcc/src/gcc-build/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/ext/atomicity.h:49

Thread 1 (Thread 0x743f5000 (LWP 344)):
#0  0x75deb49c in __gnu_cxx::__exchange_and_add (__val=-1, __mem=0x6c6d782a) at /build/gcc/src/gcc-build/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/ext/atomicity.h:49
#1  __gnu_cxx::__exchange_and_add_dispatch (__val=-1, __mem=0x6c6d782a) at /build/gcc/src/gcc-build/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/ext/atomicity.h:82
#2  std::string::_Rep::_M_dispose (__a=..., this=<optimized out>) at /build/gcc/src/gcc-build/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/bits/basic_string.h:2643
#3  std::string::assign (this=0x7e914530, __str=...) at /build/gcc/src/gcc-build/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/bits/basic_string.tcc:694
#4  0x00c9a7f4 in CXBMCTinyXML::Parse(std::string const&, std::string const&) ()
#5  0x00c9a924 in CXBMCTinyXML::LoadFile(std::string const&, TiXmlEncoding) ()
#6  0x008cd690 in CProfilesManager::Load(std::string const&) ()
#7  0x008cde20 in CProfilesManager::Load() ()
#8  0x009f0da0 in CApplication::Create() ()
#9  0x00aa59d0 in XBMC_Run ()
#10 0x002f6d9c in main ()
############# END STACK TRACE ###############

################# LOG FILE ##################



############### END LOG FILE ################

############ END Kodi CRASH LOG #############

Hier ist ein Downgrade des Paketes „tinyxml“ auf die Version 2.6.2-3 erforderlich:

[tobi@raspbpi2 ~]$ sudo downgrade tinyxml
Available packages:

   1) tinyxml-2.6.2-4-armv7h.pkg.tar.xz (local)
   2) tinyxml-2.6.2-3-armv7h.pkg.tar.xz (local)

select a package by number: 2
Lade Pakete...
Warnung: Downgrade des Paketes tinyxml (2.6.2-4 => 2.6.2-3)
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...

Pakete (1) tinyxml-2.6.2-3

Gesamtgröße der zu installierenden Pakete:  0,18 MiB
Größendifferenz der Aktualisierung:       0,00 MiB

:: Installation fortsetzen? [J/n] 
(1/1) Prüfe Schlüssel im Schlüsselring
(1/1) Überprüfe Paket-Integrität
(1/1) Lade Paket-Dateien
(1/1) Prüfe auf Dateikonflikte
(1/1) Überprüfe verfügbaren Festplattenspeicher
(1/1) Downgrading tinyxml
add tinyxml to IgnorePkg? [y/n] n
[tobi@raspbpi2 ~]$ pacman -Ss kodi-rbp
alarm/kodi-rbp 15.2-1 [Installiert]
    A software media player and entertainment hub for digital media (Raspberry Pi)
alarm/kodi-rbp-eventclients 15.2-1 [Installiert]
    Kodi Event Clients (Raspberry Pi)

…und schon läuft kodi wieder!

Bein nächsten Update bitte aufpassen, sonst macht man das Downgrade wieder rückgängig. Man kann auch die letzte Frage mit „y“ beantworten, dann wird tinyxml demnächst ignoriert.

Ergänzung vom 18.12.2015:

Ein neues Paket macht Probleme mit kodi: libcec-rpi 3.0.1.-3

sudo downgrade libcec-rpi
..
Downgrade des Paketes libcec-rpi (3.0.1-3 => 3.0.1-2)
Ergänzung vom 20.12.2015:

Alles wieder in Ordnung: upgraded kodi-rbp (15.2-1 -> 15.2-2)

Die zurückgesetzten Pakete können jetzt installiert werden und Kodi läuft in neuer Version.

letsencrypt: linuxhomeserver.de bei der „closed beta“ dabei

Letsenrypt stellt kostenlose SSL-Zertifikate zur Verfügung, um auch kleinen Webseiten die Möglichkeit zur Verschlüsselung zu geben. Die zugrunde liegende Zertifizierungsstelle „DST Root CA X3“ ist in jedem Browser als vertrauenswürdig eingestuft, somit kann man die Kommunikation zu seinen Blog komplett auf https umstellen, ohne irgendwelche Warnungen im Browser zu verursachen. Es ist eine tolle Sache, da sonst aus Kostengründen eher auf Verschlüsselung verzichtet wird. Wie auch bei mir bisher.

Ich hatte mich irgendwann Ende Oktober beim Beta-Programm von letsencrypt angemeldet. Und letztlich kam eine E-Mail mit dem Betreff „Let’s Encrypt Closed Beta Invite“. Juhu, gleich ausprobieren!

Seit heute habe ich das Zertifikat für linuxhomeserver.de im produktiven Einsatz. Endlich keine umständliche Trennung mehr zwischen unverschlüsselten Blog- und verschlüsselten Admin-Bereichen von WordPress, danke!

Thank you letsencrypt  – let’s encrypt all our websites.

Nützliche Links:

https://community.letsencrypt.org/

https://letsencrypt.readthedocs.org/en/latest/using.html

Raspberry Pi 2 ausprobiert: Installation von Archlinux mit LXQT

Ich habe eine neue SD-Card in meinen Raspberry Pi geschubst und wollte mal eine frische Archlinux-Installation raufspielen.

Vorerst wollte ich nur LXQt und Kodi installieren, nun ist doch eine nahezu komplette Desktopumgebung daraus geworden. Und so bin ich vorgegangen:

#in einen Linux-Rechner SDcard einstecken und 
#Device der SD-Card herausfinden 
sudo blkid 
#oder
sudo lsblk
#unmounten (hier im Beispiel /dev/sdi) alle Parition unmounten, SD-Card nicht auswerfen!
sudo umount /dev/sdi1
#falls mehrere Partitionen vorhanden, Beispiel für Partition Nr.1 und Nr.2
sudo umount /dev/sdi{1,2}

Weiterlesen

Archlinux setzt auf die mainline-kernel (linux-sun7i-3.4.103-5 => linux-armv7-4.0.5-2)

Achtung! Die Installationanleitung für den Cubietruck ändert sich.

Durch den offiziellen Umstieg der sun7i-kernel zur mainline-kernel der armv7h-Architektur sind folgende Dinge zu beachten:

  • Zugriff auf den NAND ist mit der derzeit aktuellen mainline-kernel noch nicht möglich, somit wird das Starten vom NAND wohl nicht funktionieren
  • Kernel-Module müssen soweit ich weiß nicht mehr manuell geladen werden. Ein erste Versuch mit der Kernel linux-armv7-4.0.5-2 hat automatisch folgende Module geladen
    • realtek
    • brcmfmac
    • brcmutil
    • stmmac_platform
    • cfg80211
    • stmmac
    • evdev
    • sun4i_ts
    • pwm_sun4i
    • rfkill
    • uio_pdrv_genirq
    • uio
    • sch_fq_codel

Weiterlesen

Grundinstallation Archlinux cubietruck (Teil 3): NAND-Flash bootet mit SATA-SSD

ACHTUNG! Erster Entwurf aus meinen Notizen ohne genaue Erklärungen.
!!!Bitte mitdenken!!!
Voraussetzung: Archlinux komplett auf SD-Card installiert und funktioniert

    Prinzipiell funktioniert es so:
  • NAND partitionieren/formatieren
  • NAND mit Archlinux bestücken
  • vom NAND booten
  • SSD formatieren
  • SD-Card-root auf SSD (sda1) kopieren
  • Neustart ohne SD-Card

zuerst von SD-Card booten = NAND wird nicht benutzt

# erforderliche Programme installieren 
pacman -S sunxi-tools dosfstools wget 

Weiterlesen

Grundinstallation Archlinux cubietruck (Teil 2): Arch-Grundeinstellungen, Kernel-Module und Netzwerk einrichten

  • Verbindung mit dem gestarteten cubietruck herstellen
  • Standard-Anmeldung der Archlinux Installation
    login: root
    password: root

    Von einem anderen Rechner

    1. entweder über USB UART-Kabel
      sudo screen /dev/ttyUSB0 115200
    2. oder über funktionierende Netzwerkverbindung und ssh (standard-hostname?=alarm)
      ssh root@alarm

    Im Notfall kann man auch versuchen, eine Tastatur und einen Monitor an den Cubietruck dranzuhängen.

  • Spracheinstellungen und Zeitzone

Weiterlesen

Grundinstallation Archlinux cubietruck (Teil 1): Zielsetzung und erster Start

Das Ziel der Installation war es, nicht nur den cubietruck zum Laufen zu bekommen, sondern auch die eine möglichst optimale Bootkonfiguration zu erreichen.

  1. Zielsetzung der Grundinstallation:
  • Root-Dateisystem auf SATA (z.B. SSD)
  • Booten ohne SD-Karte
  • NANDa wir nur für den uboot benutzt, der restliche Speicher im NAND wird zur weiteren Verwendung vorbereitet
  • Updates über pacman zerstören das System nicht, Anpassung der Pakete an den cubietruck
  • (noch in Arbeit: Backuplösung über SD-Card und/oder NAND)

Doch zuerst muss das Betriebssystem auf eine SD-Karte kopiert werden. Quelle: http://archlinuxarm.org/platforms/armv7/allwinner/cubieboard-2
ACHTUNG!: Die SD-Karte wird vollständig gelöscht und überschrieben!!!

Im folgenden Beispiel wird auf einem Zweitrechner die SD-Karte vorbereitet. Die Karte ist als /dev/sdi im System vorhanden. Weiterlesen