Tumbleweed – FRITZ!Box – MyFRITZ! Service

Der Leser meinte: Yesterday, I came across a very helpful article here https://forums.opensuse.org/t/tumbleweed-fritz-box-myfritz-service/184274 about best practices for configuring IPv6 on routers, including some practical examples using a Fritz!Box. I bookmarked the post to review it again, but I noticed it was hidden less than 24 hours later.

Die Administratoren meinten: Your post was flagged as **spam**: the community feels it is an advertisement, something that is overly promotional in nature instead of being useful or relevant to the topic as expected.

Na ja. Hier steht er und keiner wird ihn mehr verstecken:

Configuring IPv6 in the FRITZ!Box is very terse on Linux:

Linux and other devices (for example NAS systems)

1. Configure the device to automatically obtain an IPv6 address and a DNSv6 server via SLAAC und DHCPv6. Refer to the manufacturer for information on how to set it up, for example consult the manual.

Applying KISS to FRITZ!Box and NetworkManager configuration removes virtually all annoyances related to networking:

1. Enable the options “Enable DHCPv6 server in the FRITZ!Box for the home network” and “Only assign DNS server” in the section “DHCPv6 Server in the Home Network”.
   
2. NetworkManager:
   [ipv6]
addr-gen-mode=eui64
ip6-privacy=0
   method=auto
   
3. The above steps result in the following minimal host configuration:
   erlangen:~ # host erlangen
erlangen.fritz.box has address 192.168.178.22
erlangen.fritz.box has IPv6 address 2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
erlangen.fritz.box has IPv6 address fdad:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
erlangen:~ #
   
4. Free MyFRITZ! service grants access to IHE e.g. via ssh://erlangen.xxxxxxxxxxxxxxxxxxxxx.myfritz.net.

Grub – EFI – Btrfs

Seit 2019 gab es eine Änderung. Nun ist ein zusätzlicher Mount erforderlich.

mount /dev/sdb5 /mnt          # System Partition
mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount -o bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars
chroot /mnt
mount /dev/sdb1 /boot/efi     # EFI System Partition
grub2-install
update-bootloader
exit

Völlig ab vom Thema – und ich falle auch noch immer wieder d’rauf rein

So jammert Dr. rer. nat. Christian Meesters, als „Computational Scientist“ tätig im HPC-Team der Universität Mainz: http://scienceblogs.de/rupture-de-catenaire/2020/07/04/software-in-der-bioinformatik-4-warum-bioinformatikerinnen-von-einer-arbeit-in-nicht-it-arbeitsgruppen-sehr-vorsichtig-sein-sollten/#comment-797

Meine Interpretation des Sachverhalts: Die Kommentare bringen es auf den Punkt und der Arme präsentiert eine Ausrede.

openSUSE Leap 15.2

Heute Nachmittag wird die Version 15.2 von openSUSE Leap erscheinen. Unzählige Testberichte werden beschreiben, wie schwierig und umständlich die Installation ist.

Lange Jahre hat openSUSE die Benutzer vernachlässigt. Die Auswirkungen waren nachhaltig: Niemand will wahrhaben, dass openSUSE die Kritikpunkte längst ausgeräumt hat. Nimmt man die einfache Wartbarkeit als Maßstab liegt es in puncto Benutzerfreundlichkeit längst an der Spitze.

Schon am Morgen habe ich das DVD-Image heruntergeladen und auf einen USB 3.0 Stick kopiert. Der Installer lädt zügig, mit einem Klick ist der Installationsumfang ausgewählt. Sprache und Zeitzone sind mit je einem Klick ausgewählt. Die manuelle Partitionierung ist einfacher als bei allen anderen bekannten Distributionen. Die Benutzer werden mit einem Klick aus einer vorhandenen Installation übernommen. Um 9:04 Uhr startet die Installation, nach sieben Minuten ist sie beendet.

Die Aktualisierung mit „zypper update“ dauert 38 Sekunden. Änderungen nach Erstellen des DVD-Images und aktuelle Patches sind nun angewendet

Die angeblich so komplizierte Installation der proprietären Codecs erfolgt in wenigen Sekunden durch Kopieren und Einfügen zweier Kommandos in eine root Shell:

zypper addrepo --refresh --priority 90 'http://ftp.fau.de/packman/suse/openSUSE_Leap_$releasever/' packman

zypper dist-upgrade --allow-vendor-change --allow-downgrade --from packman

Grub – EFI – Btrfs

Vor drei Jahren war die Reparatur von Grub schon einmal ein wichtiges Thema. Seither wurden die Rechner auf EFI umgestellt und die Systempartition verwendet nun btrfs statt ext4. Gründe genug, die Prozedur zu revidieren und zu testen:

mount /dev/sdb5 /mnt          # System Partition
mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
chroot /mnt
mount /dev/sdb1 /boot/efi     # EFI System Partition
grub2-install
grub2-mkconfig -o /boot/grub2/grub.cfg
exit

It’s not a trick, it’s Snapper running on openSUSE

In 2016 hatte ich schon einmal probiert, doch die Erfahrung war nicht so toll: Corrupted-BTRFS? Drei Jahre später sieht die Sache ganz anders aus: Btrfs-Snapper-Amazing-Stuff!

Nach langer Abstinenz hatte ich wieder einmal openSUSE Tumbleweed auf btrfs installiert. Ich war skeptisch und habe natürlich sofort ausprobiert, ob es auch tatsächlich funktioniert. Nach Eintippen von snapper rollback 123 habe ich die Maschine gebootet und der Rechner hat alles vergessen, was nach Snapshot 123 schief gegangen ist.

Die Installation ist tatsächlich wartungsfrei. Allzu sorglosen Benutzern kann es passieren, dass die Platte überläuft. Dann ist guter Rat teuer. Freundlicherweise hat jemand aufgeschrieben wie man schnell wieder zu einem funktionierenden System kommt: btrfs out-of-space emergency response/ und: http://marc.merlins.org/perso/btrfs/post_2014-05-04_Fixing-Btrfs-Filesystem-Full-Problems.html

Ursprünglich hatte ich eine längere Übergangsphase angedacht. Die Verbesserungen von Snapper/Btrfs waren aber so überzeugend, dass ich möglichst schnell die Installation vervollständigen und zu meinem primären System machen werde. Das bisherige System auf ext4 dient dann als Backup. Den braucht man eigentlich nie. Falls man im Notfall einen hat ist es eine feine Sache.

Nach einem Vierteljahr gibt es nur wenig zu mäkeln. Die Btrfs maintenance toolbox nimmt einem die notwendigen Wartungsarbeiten ab. Sie hat hat allerdings eine kleine Macke, die auf den meisten Systemen den Bootvorgang verzögert, im schlimmsten Fall allerdings sehr ärgerlich ist: https://github.com/kdave/btrfsmaintenance/pull/81

Lichtkurven

JPG

openSUSE auf dem Notebook – YMMV

Vor 10 Jahren habe ich bereits die Anschaffung eines Notebooks erwogen. Schließlich wurde es doch wieder ein Desktop. Notebooks waren damals verhältnismäßig teuer und boten wenig Leistung.

Heute sieht die Sache anders aus. Nach einigem Stöbern entschloss ich mich für ein ganz gewöhnliches HP 15 da0103ng für 444 €. Das wurde allerdings mit FreeDOS geliefert.

Wegen der seit 2016 guten Erfahrung auf dem Desktop installierte ich openSUSE Tumbleweed auch auf dem Notebook.

Eigentlich ist das vollkommen unverständlich, kursieren doch einschlägige Erfahrungen wie die von Dedoimedo: „OpenSUSE Leap 15 is a troubled distro. … Unfortunately, Leap 15 is a no-go. Something like 1/10. Me very sad.“

Zu ähnlichem Gejammere habe ich keinen Anlass. Ich lade das openSUSE Tumbleweed Net Image herunter und kopiere es auf einen USB-Stick. Das Notebook verbinde ich mit der Fritz!Box und boote vom Stick. Als Sprache wähle ich Deutsch. Die eingebaute SSD formatiere ich im Experten-Modus mit EFI- (fat) , System – (ext4)  und Home Partition (ext4). Alles andere kann bleiben wie es ist und das System installiert sich ohne weiteres Zutun.

Nach dem Booten passt alles. Wie erwartet bietet der NetworkManger nur den Flugmodus an. Ich suche bei https://software.opensuse.org/explore nach dem Treiber für den RTL8821CE des Notebooks, installiere und boote: fertig! Der NetworkManager listet zahlreiche Verbindungen auf. Ich wähle meine Fritz!Box aus und bin nun auch drahtlos unterwegs. Proprietäre Module lade ich von  http://ftp.fau.de/packman/suse/openSUSE_Tumbleweed/ herunter.

Der Verkäufer bittet nach einigen Tage um Rückmeldung. Mein Kommentar: „Das bestellte Notebook HP 15-da0103ng traf pünktlich ein. Das vorinstallierte FREEDOS wurde durch openSUSE Tumbleweed ersetzt. Damit erfüllt das Gerät die geweckten Erwartungen zur vollsten Zufriedenheit.“

So recht will die Geschichte keiner glauben und endlich muss ich richtigstellen.

 

 

Frühjahrsputz

Auf ihn kann ich gerne verzichten und bedaure die Leute, die es um diese Jahreszeit übertreiben. Doch heuer mache ich eine Ausnahme und räume den PC auf.

Seit ich Tumbleweed einsetze wird das Betriebssystem von openSUSE wöchentlich oder sogar öfter aktualisiert. So kann ich mich auf die eingebauten Festplatten konzentrieren. In 2014 startete ich mit einer SSD-Platte mit 60 GB und einer HDD mit 2 TB. Das war bald unbefriedigend, so dass ich die SSD erst auf 250 GB und schließlich auf 500 GB vergrößerte:

hofkirchen:~ # inxi -D
Drives: HDD Total Size: 2750.6GB (69.2% used)
 ID-1: /dev/sda model: Samsung_SSD_850 size: 500.1GB
 ID-2: /dev/sdb model: ST2000DM001 size: 2000.4GB
 ID-3: /dev/sdc model: Samsung_SSD_850 size: 250.1GB
hofkirchen:~ #

Die kleine SSD bietet nun einen Backup des Betriebssystems, ein Reparatursystem sowie viel Platz zum Ausprobieren.

Das Board habe ich vom Kompatibilitätsmodus auf EFI umgestellt. Endlich ist das (optionale) Bootmenü so einfach und klar wie ich es mir immer vorgestellt habe:

hofkirchen:~ # efibootmgr 
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001
Boot0000* opensuse
Boot0001* opensuse.repair
hofkirchen:~ #

Standardmäßig wird von der großen SSD gebootet, optional von der kleinen.

Die Umstellung des Bootladers Grub2 auf EFI klappte nur mit Lerneffekt, siehe unten. Dabei gibt es nur wenig zu tun.

1. Einrichtung einer neuen Partition und Installation von Grub2 EFI:

hofkirchen:~ # df /boot/efi/
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 102182 126 102056 1% /boot/efi
hofkirchen:~ # grub2-install --target=x86_64-efi --no-nvram
Installing for x86_64-efi platform.
Installation finished. No error reported.
hofkirchen:~ #

2. Hinzufügen des Laders zum EFI Bootmenü:

hofkirchen:~ # efibootmgr --create --disk /dev/sda --part 1 --label test --loader /EFI/opensuse/grubx64.efi
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0002,0000,0001
Boot0000* opensuse
Boot0001* opensuse.repair
Boot0002* test
hofkirchen:~ #
hofkirchen:~ # find /boot/efi/
/boot/efi/
/boot/efi/EFI
/boot/efi/EFI/opensuse
/boot/efi/EFI/opensuse/grubx64.efi
hofkirchen:~ #

Die Vereinfachung gegenüber der althergebrachten Prozedur ist erheblich. Als Bonus ist auch YaST > Bootloader so einfach geworden, dass man auch ohne lange nachzudenken die gewünschten Optionen erwischt:

openSUSE Tumbleweed
Erweiterte Optionen für openSUSE Tumbleweed
openSUSE Tumbleweed, mit Linux 4.16.7-1-default
openSUSE Tumbleweed, mit Linux 4.16.7-1-default (Wiederherstellungsmodus)
openSUSE Tumbleweed, mit Linux 4.16.6-1-default
openSUSE Tumbleweed, mit Linux 4.16.6-1-default (Wiederherstellungsmodus)

openSUSE Leap 42.3 (auf /dev/sdb1)
Erweiterte Optionen für openSUSE Leap 42.3 (auf /dev/sdb1)
openSUSE Leap 42.3 (auf /dev/sdb1)
openSUSE Leap 42.3, mit Linux 4.4.85-22-default (auf /dev/sdb1)
openSUSE Leap 42.3, mit Linux 4.4.85-22-default (Wiederherstellungsmodus) (auf /dev/sdb1)
openSUSE Leap 42.3, mit Linux 4.4.76-1-default (auf /dev/sdb1)
openSUSE Leap 42.3, mit Linux 4.4.76-1-default (Wiederherstellungsmodus) (auf /dev/sdb1)

openSUSE Tumbleweed (auf /dev/sdc2)
Erweiterte Optionen für openSUSE Tumbleweed (auf /dev/sdc2)
openSUSE Tumbleweed (auf /dev/sdc2)
openSUSE Tumbleweed, with Linux 4.16.6-1-default (auf /dev/sdc2)
openSUSE Tumbleweed, with Linux 4.16.6-1-default (recovery mode) (auf /dev/sdc2)

openSUSE Tumbleweed (auf /dev/sdc3)
Erweiterte Optionen für openSUSE Tumbleweed (auf /dev/sdc3)
openSUSE Tumbleweed (auf /dev/sdc3)
openSUSE Tumbleweed, with Linux 4.16.7-1-default (auf /dev/sdc3)
openSUSE Tumbleweed, with Linux 4.16.7-1-default (recovery mode) (auf /dev/sdc3)
openSUSE Tumbleweed, with Linux 4.16.6-1-default (auf /dev/sdc3)
openSUSE Tumbleweed, with Linux 4.16.6-1-default (recovery mode) (auf /dev/sdc3)

Ich bedauere nur, dass ich nicht schon früher aufgeräumt habe! Details

Lerneffekt: YaST2 Partitioner und YaST2 Boot Loader sind angenehm zu bedienende Werkzeuge für die Konfiguration der Festplatten. Sie arbeiten meist sehr zuverlässig. Im Zweifelsfall sollte man aber unbedingt durch den Befehl dracut -f eine konsistente initrd erstellen und Grub2 durch den Befehl grub2-install –target=x86_64-efi installieren. Man erspart sich damit viel Herumprobieren.

Der Krampfbeutl

Lange habe ich über einer Überschrift für den Beitrag gegrübelt. Schließlich bin ich fündig geworden und möchte mich beim Kollegen dafür bedanken:

„Wenn eine Frau mit allem und jedem angibt und dies auch jedem zeigen und mitteilen muss, dann ist das eine Krampfhenna. Das männliche Pendant dazu ist der Krampfbeutl.“

Der Sachverhalt ist einfach, doch was ein ehrgeiziger Krampfbeutl daraus machen kann erstaunt dennoch. Und stänkern tut er auch gerne: Webspace

Neues vom Krampfbeutl: Alles was er nicht kennt ist ein Bug.

Er ist nicht der hellste und dokumentiert das auch: Upload Maladies