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
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.
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
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
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
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.
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.
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
Viele Jahre lange habe ich die Standardeinstellungen verwendet, doch nun ist Zeit für einen Wechsel.
~ # postconf home_mailbox=.local/share/local-mail/inbox/
~ # systemctl restart postfix
~ #Wie immer im richtigen Leben können Probleme auftauchen, bei der derzeitigen Version von Postfix ein Konfigurationsfehler: Bug 1057349. Abhilfe schaffen folgende Kommandos:
~ # postconf -# smtpd_sasl_type
~ # postconf -# smtpd_sasl_path
~ # systemctl restart postfix
~ #
Auch das schadet nicht:
postconf -e 'myhostname = localhost'
| Grub – EFI – Btrfs |… bei Grub – EFI – … | |
 | stiller Leser bei Bullstuff vom Atheisten |
 | Karl bei Bullstuff vom Atheisten |
| stiller Leser bei Bullstuff vom Atheisten |
| Karl bei Bullstuff vom Atheisten |
Karl Mistelberger 