Fedora 30&31 Bootumstellung führt zu Startproblem

Eigentlich wollte ich was von Endlosschleifen sagen, aber das trifft es nicht, auch wenn eine Schleife als Folge möglich ist. Neulich habe ich auf Fedora 30 Updaten müssen, dabei gab es eine Reihe von Pannen, bei deren Lösung Ihr ab sofort hier nachschlagen könnt.

Die Umstellung auf BLS

Schuld ist die BLS Umstellung in Grub, die zu einigen Verwirrungen und Irrungen geführt hat. Natürlich hat das Suchen mal wieder deutlich mehr Zeit in Anspruch genommen, als das Beheben des resultierenden Problems. Wer rechnet schon mit einer bis Dato unbekannten Bootmichtodschleife? Zugegeben, in meinem Spezialfall war es mehr Tod als Schleife, aber ohne viel Fantasie kann man auch eine Schleife damit bauen.

Die BootLoader Specification kurz BLS kann man an einem passenden Eintrag in der /etc/defult/grub erkennen:

# cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DEFAULT=saved

GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT=“gfxterm“
GRUB_ENABLE_BLSCFG=true

Ich hab ein bisschen was weggelassen, damit es leserlicher wird. Wenn BLS aktiv ist, habt Ihr die Booteinträge nicht mehr in der grub2.cfg stehen, sondern hier:

# ls -la /boot/loader/entries/
insgesamt 16
4 -rw-r–r–. 1 root root 379 28. Nov 00:19 7e390913b33b4e5ba8f960a9ba97aeee-0-rescue.conf
4 -rw-r–r–. 1 root root 249 22. Nov 00:15 7e390913b33b4e5ba8f960a9ba97aeee-5.3.12-200.fc30.x86_64.conf
4 -rw-r–r–. 1 root root 249 26. Nov 00:28 7e390913b33b4e5ba8f960a9ba97aeee-5.3.13-200.fc30.x86_64.conf
4 -rw-r–r–. 1 root root 249 2. Dez 17:22 7e390913b33b4e5ba8f960a9ba97aeee-5.3.14-200.fc30.x86_64.conf

Diese Änderung unterstütze ich voll und ganz, da muß man keine unnötigen rebuilds der grub.cfg machen. Einfach neues File rein, oder altes raus. Fertig. Soweit, so gut.

Die Probleme zeigen sich jetzt bei diesem Punkt: „/etc/grub.d/08_fallback_counting“  Da wird mitgezählt, ob wir einen funktionierenden Boot hatten, oder nicht. Wenn der Rechner z.b. beim Boot nicht hochkommt, wird automatisch ein anderer Kernel benutzt, als zuletzt zum Booten eingestellt war. Im Idealfall behebt sich ein Bootproblem somit von allein.

An sich wäre das ok, wenn genau dieser Algorithmus auch sauber funktionieren würde, tut er aber nicht.

Prämisse: Der Rechner bootet nicht durch, Ihr wählt im Kernelmenü einen anderen Kernel aus.

Wenn man den 08-Fallbackcode liest, stellt man fest, daß im Fall der Erkennung des „nicht sauber gebootet“ Zustands, die Auswahl des Kernels, die man selbst gemacht hat, mit dem Defaultwert 1 überschrieben wird. „1“ meint hier den Kernel-Index 1, also den Kernel an Position 2 in der Liste!

insmod increment
# Check if boot_counter exists and boot_success=0 to activate this behaviour.
if [ -n "\${boot_counter}" -a "\${boot_success}" = "0" ]; then
   # if countdown has ended, choose to boot rollback deployment,
   # i.e. default=1 on OSTree-based systems.
   if [ "\${boot_counter}" = "0" -o "\${boot_counter}" = "-1" ]; then
      set default=1
      set boot_counter=-1
      # otherwise decrement boot_counter
   else
      decrement boot_counter
   fi
   save_env boot_counter
fi

Und bei der „set default=1“ Zeile liegt das Problem, denn was da Index 1 ist als Kernel, ist nicht definiert.

Das Fallbackproblem ist auch dann wirksam, wenn man kein BLS aktiv hat. In diesem Fall läßt es sich besser nachvollziehen, deswegen setzen ich das jetzt mal voraus. Die grub.cfg könnte dann so aussehen:

### BEGIN /etc/grub.d/08_fallback_counting ###
insmod increment
# Check if boot_counter exists and boot_success=0 to activate this behaviour.
if [ -n "${boot_counter}" -a "${boot_success}" = "0" ]; then
  # if countdown has ended, choose to boot rollback deployment,
  # i.e. default=1 on OSTree-based systems.
  if  [ "${boot_counter}" = "0" -o "${boot_counter}" = "-1" ]; then
    set default=1
    set boot_counter=-1
  # otherwise decrement boot_counter
  else
    decrement boot_counter
  fi
  save_env boot_counter
fi
### END /etc/grub.d/08_fallback_counting ###

BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora (5.3.14-200.fc30.x86_64) 30 (Thirty)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-5.3.14-200.fc30.x86_64-advanced-dca7eea1-687e-476a-a9a0-c41ef0329113' {
...
}
menuentry 'Fedora (5.3.13-200.fc30.x86_64) 30 (Thirty)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-5.3.13-200.fc30.x86_64-advanced-dca7eea1-687e-476a-a9a0-c41ef0329113' {
...
}
menuentry 'Fedora (5.0.17-200.fc29.x86_64) 30 (Thirty)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-5.0.17-200.fc29.x86_64-advanced-dca7eea1-687e-476a-a9a0-c41ef0329113' {
...
}

Das ergibt :

Kernel-Index=0 => „5.3.14-200.fc30.x86_64“
Kernel-Index=1 => „5.3.13-200.fc30.x86_64“
Kernel-Index=2 => „5.0.17-200.fc29.x86_64“

Merke, in dem Fallback steht 1 als Fallbackoption drin.

Das Xen Problem

Wenn jetzt die neueren Kernels von Fc30 nicht bootet, weil die z.b. in einer XenUmgebung laufen, wo ein alter pyGrub Bootloader am werkeln ist, dann funktioniert der Boot nicht. d.b. der nächste Boot funktioniert auch nicht, weil die Fallbackoption auf einen Kernel zurückgreift, der auch nicht funktioniert.

Wenn man jetzt in der grubenv den Kernel-Index=2 ausgesucht hat, z.b. so „saved_entry=Fedora (5.0.17-200.fc29.x86_64) 30 (Thirty)„, dann wird dies wie oben beschrieben ignoriert, weil der FallBackcode nach dem Defaultkernelcode in der Grub.cfg kommt.

Ihr könnt auch tausendmal auswählen, daß Ihr den Kernel haben wollt, ist egal, wird auch überschrieben.

Die Lösung

Da hilft nur eine Aktion: „set default=2“ in die grub.cfg schreiben. Das wird natürlich beim nächsten Kernelinstall übergenagelt, aber a) könnt Ihr das auch in der /etc/grub.d/08-…. anpassen, dann bleibt es erhalten und b) in obiger Prämisse rebootet Ihr eh nicht 😉 hauptsache das System kommt überhaupt hoch.

Jetzt muß keiner glauben, daß das Problem unbekannt wäre, es gibt Bugreports dazu von Fedora 30 Tage 1 an. Weil das Problem für Xen als Bugreport bekannt war, wurde die Upgraderoutine so umgeschrieben, daß BLS deaktiviert ist, wenn Xen als Host gefunden wird. Das alleine schützt aber nicht vor dem Fallbackproblem.

Grubby

Das nächste Problem: grubby. Grubby ist das kleine Shelltool, daß die Grubenv erzeugt, wenn z.b. sagt, welchen Kernel man als Default haben will, Ihr erinnert euch: Grubby: wie man wieder einen Default Kernel setzen kann.

Tja leider ist Grubby wohl nicht ganz mitgekommen und schreibt BLS Kernelinformationen in die grubenv, auch wenn BLS abgeschaltet ist. Da könnt Ihr nur von Hand eingreifen und die grubenv manuell beheben. Aber achtet auf die 1024 Zeichenlänge der grubenv, die muß erhalten bleiben!

Kleines Update:

Wenn man jetzt so danach googelt, findet man jede Menge Hinweise, daß bei dem Upgradeprozess etwas schief gehen wird. Ich komme mehr und mehr zu dem Schluß, daß es eine ganz schlecht geplante Aktion war.

Anstelle von Grubby für den Kerneleintrag zubenutzen, kann man auch folgendes machen:

grub2-editenv /boot/grub2/grubenv set „saved_entry=Fedora (5.3.13-200.fc30.x86_64) 30 (Thirty)“

Natürlich mit dem Kerneleintrag den Ihr wollt 😉

Wie kommt man an diese Bezeichnung?

grep ^menuentry /boot/grub2/grub.cfg | cut -d „‚“ -f2

kommt dies bei raus:

Fedora (5.3.15-200.fc30.x86_64) 30 (Thirty)
Fedora (5.3.14-200.fc30.x86_64) 30 (Thirty)
Fedora (5.3.13-200.fc30.x86_64) 30 (Thirty)
Fedora (0-rescue-9aa92939e4c644e6aa3e09cc4c2311e8) 30 (Thirty)

Jetzt braucht Ihr den Titel nur noch zu kopieren und an den grub2-editenv zu übergeben.

Firefox 71: Layout via userChrome.css nachbessern

Wer gestern seinen Webbrowser geöffnet und u.a. meine Layoutanpassungen laufen hat, wird vermutlich einen grauen Block vorgefunden haben. Das lässt sich leicht lösen.

Firefox 71 – TabsToolBar anpassen

Wir brauchen einen Texteditor. Mit diesem öffnet Ihr die folgende Datei: ~/.mozilla/{profilname}/chrome/userChrome.css und ändert den #TabsToolbar Block in:

#TabsToolbar { /* tab bar */
    -moz-box-ordinal-group: 3 !important;
    padding-top: 0px !important;
    top: 92px;
    position: absolute;
    display: block;
}

Abspeichern. Browser neustarten. Geht wieder!

 

 

AfD Parteitag in Braunschweig, was ist schlimmer?

Wie ich vor einigen Jahren mal aufgedeckt habe, lief gegen die AfD ein versteckter Feldzug: Follow-Up: Tor vs. AfD – NSA-Style. Eine oberflächliche Prüfung hat jetzt ergeben, daß diese Aktion zuletzt im Sommer 2018 gelaufen ist. Seitdem gibt es keine Spuren mehr davon, oder anderer verdeckter Aktionen.

AfD Parteitag in Braunschweig

Jetzt haben wir 2019 und in Braunschweig findet der Bundesparteitag der AfD in der „“ Halle statt. “ „“ Halle? “ werdet Ihr fragen, ja „“ Halle. Die Volkswagenhalle, wie Sie früher hies, wurde kurzerhand zugelabelt in „“, sprich „{nichts}“. Allen Ernstes wurde der Schriftzug mit schwarzgrauen Teilen abgedeckt. VW will seinen Namen dabei nicht im Fernsehen sehen, als wenn keines der anwesenden Fernsehteams das aufnehmen und breittreten würde 😀 So etwas kann man nur als kindisch bezeichnen.

Behinderungen in Braunschweig

Ich hatte ja in dem Tor vs. AfD – NSA Style Beitrag damals geschrieben, daß mir die AfD egal ist, ist sie mir heute auch noch und zwar im gleichen Maße wie CDU, SPD, Grüne, Gelbe, Blaue oder sonst wie in den Farbtopf gefallene Politikerbanden. Was einem aber nicht egal sein sollte, sind die Konsequenzen die der Hass auf die AfD hervorbringt. Wenn man kurz bei der kommerziellen Presse nachschaut ..

https://www.news38.de/braunschweig/article227770029/AfD-Bundesparteitag-Braunschweig-Mit-DIESEN-Einschraenkungen-muessen-Buerger-rechnen.html

.. befindet sich Braunschweig, welches so um die 250.000 Einwohner hat, derzeit im Krieg. Im Krieg mit Gegendemonstranten, die durch Ihr wahrgenommenes Recht gegen etwas zu demonstrieren, seit heute morgen Braunschweig in Teilen lahmlegen. In der Pressemitteilung der Polizei Braunschweig heißt es:

„Friedlichkeit ist das Gebot der Stunde“, so beschreibt Polizeipräsident Michael Pientka seine Erwartung. Es ist sehr erfreulich, dass es viele Aufrufe für friedlichen Protest gibt. Und auch die Sprecher des „Bündnisses gegen Rechts“ bestärken dies mit ihrer Ankündigung, dass es „keine Gewalt geben wird“. Ich finde es sehr beachtlich, wie konstruktiv und respektvoll die Zusammenarbeit im Vorfeld zwischen allen verantwortlichen Bereichen war. Für die Polizei bedeutet dieses Wochenende eine große Herausforderung. Unterstützt werden wir dabei durch andere niedersächsische Polizeibehörden und die Polizeien anderer Bundesländer.“ ( Quelle: https://www.presseportal.de/blaulicht/pm/11554/4453294 )

Die Polizei Braunschweig hat große Erfahrung mit Menschenmassen, da hier der Schoduvel stattfindet, das ist der Braunschweiger Karnevalsumzug zu dem jedes Jahr zwischen 100.000 und 250.000 Leuten kommen, also weit mehr als die paar Demonstranten, die dies Wochenende hier sein werden. Umso mehr schockt einen natürlich die Aussage, daß sich die Polizei aus anderen Bundesländern Verstärkungskräfte besorgen muß, obwohl ja alle Teilnehmergruppen Gewaltfreiheit gelobt haben. Wie viel so ein Versprechen offensichtlich wert ist, zeigen die Maßnahmen der Polizeiführung, die da wohl nicht wirklich dran glaubt.

Gewaltpotential im Vorfeld

Wie schlimm das mit der AntiFa werden könnte, zeigt diese Mitteilung der AfD selbst:

Wichtiger Hinweis: Das Delegiertentreffen zum Vorfeld des Bundesparteitags in Braunschweig muss, aufgrund der maximalen Bedrohungslage durch linksterroristische Kräfte, leider ausfallen!

Quelle: https://www.news38.de/braunschweig/article227057221/AfD-Bundesparteitag-Braunschweig-Bedrohungslage-Fluegel-Treffen-abgesagt.html

Zur Info: „Der Fügel“ ist die extreme Seite der AfD um Bernd Höcke herum.

So egal mir die AfD ist, aber der Gewalt durch Extremisten jeglicher Couleur, egal ob Links, Rechts oder IS muß  Einhalt geboten werden. Eine Demokratie kann viele Meinungen aushalten, ja muß sich diese sogar zu eigen machen und zur Schau stellen, aber sie kann keine Gewalt gegen Ihre Meinungsträger tolerieren.

Schauen wir mal, wie das Wochenende so wird, ich versuch mich mal durch zuschlagen, bevor man gar nicht mehr durchkommt. Fast hätte ich es vergessen, zu den Politik-Demonstranten kommen ja noch die Friday-4-Future Demonstranten, die auch ausgerechnet heute gegen den Klimawandel protestieren wollen. Das wird ein Demonstrantengelage sondergleichen 😀

Neue Schwachstelle im Fedora Systemdesign?

Travis Ormandy, genau der vom Google Security Team, hat bei Red Hat und Fedora im April 2019 einen Securityreport eingebracht, daß eine Änderung zum Setzen von Bootflags, jetzt die Tendenz hat, extrem leicht dem Bootprozess zu stören.

SUID für grub2-set-bootflag

„grub2-set-bootflag“ ist ein Befehl aus der Bootloaderedition, der zwei Argumente annimmt. Aufrgund der Argumente verorte ich das mal im FastBootBereich des Systemstarts, weil es augenscheinlich um so Sachen wie schnelleres Laden, wenn Booten schon einmal erfolgreich war, geht.

Das Problem

$ ls -l `which grub2-set-bootflag`
-rwsr-xr-x. 1 root root 20272 Oct 10 00:35 /usr/sbin/grub2-set-bootflag

Wie man unschwer sehen kann, ist das ein Programm, daß man als User ausführen kann und dann Dinge als Root tut. Um genau zu sein, es schreibt eine Bootoption in die grubenv abhängig vom Argument. Ohne erst einmal ein halbes Dutzend Bugreports zu lesen, die grubenv enthält so Sachen wie „welchen Kernel soll ich booten“ und ist extrem anfälliger Bockmist.

Ja,Ja, ich hörs schon wieder, ich soll nicht so auf anderer Leute Arbeit rumhacken 🙂 Also erkläre ich das mal, dann verstummt Ihr von alleine 😉 Das ist Bockmist weil, die grubenv muß EXAKT 1024 Zeichen lang sein, um vom Bootloader verarbeitet werden zu können. Ist sie kleiner oder größer, wird sie ignoriert … und auch nie wieder beim Update der Bootconfig gefixt.

Woher ich das weiß, na von dem halben Dutzend Bugreports über die letzten Jahre, die Andere und ich zu dem Thema bei Red Hat abgesetzt haben und Ihr könnt mir glauben, die ziehen sich extrem unnötig in die Länge.

Immer mal wieder passiert es nämlich, daß grubby die grubenv selbst sabotiert. Unwissentlich passiert das, wenn jemand von Hand an der grubenv rumeditiert um z.b. einen anderen Kernel einzustellen. Macht das nicht! Nehmt Grubby dafür! Grubby: wie man wieder einen Default Kernel setzen kann

Um die exakte Dateilänge von 1024 zu erreichen, wird in die grubenv eine Reihe von abgezählten „#“ Padzeichen eingefügt. Könnt ja mal reinsehen. Wenn jetzt also jemand dort Optionen einbringt und der Grubenv-Block wird zu groß, oder zu klein, dann fällt das System auf die Defaults zurück.

Was im Zweifel bedeutet: Es bootet nicht mehr!

Welchen Grund wird es wohl gehabt haben, daß jemand einen anderen Kernel eingetragen hat? Genau 😉

Boot Loader Specification

Mit Fedora 30 wurde im Bootbereich auch Einiges geändert, so stehen die Kernels nicht mehr in der grub.conf drin, sondern finden sich jetzt in /boot/loader/entries/ als einzelne Dateien wieder und die saved_entry Variable in der grubenv referenziert nur noch einen dortigen Dateinamen.

Jetzt kommt Travis ins Spiel

Travis hat also aufmerksam die Publikationen von Fedora verfolgt und stolperte über das Problem mit dem Setuid. Damit kann nämlich jeder Benutzer, und damit Programm, diesen Grub2 Befehl ausführen. Würde das mit der grubenv stabil laufen, wäre das noch kein Problem.

Jetzt hat Travis aber einen Weg ersonnen, wie man als User die grubenv unbrauchbar machen kann, indem man z.b. das Padding zerstört ( siehe Bockmist oben ).

$ sudo egrep -bo ‚^##‘ /boot/grub2/grubenv
322:##

Zum Ermitteln wieviele ## da als Padding drin sind. Es geht aber auch pauschal mal eine 10 Byte lange Datei , kommt aufs gleiche raus.

python
Python 2.7.16 (default, Apr 30 2019, 15:54:43)
[GCC 9.0.1 20190312 (Red Hat 9.0.1-0.10)] on linux2
Type \“help\“, \“copyright\“, \“credits\“ or \“license\“ for more information.
>>> import resource
>>> import os
>>> resource.setrlimit(resource.RLIMIT_FSIZE, (323,323))
>>> os.execlp(\“grub2-set-bootflag\“, \“grub2-set-bootflag\“, \“menu_show_once\“)
Error flushing /boot/grub2/grubenv: File too large

Das Pythonbeispiel begrenzt also die Filelänge für sich und alle Subprozesse und Ihr ahnt es schon, das wirkt sich auch auf den per SUID aufgerufenen Prozess von Grub aus.

Ergebnis: Grubenv zerstört, Booteinstellungen auf Defaults zurückgesetzt und ggf. System damit unbrauchbar gemacht.

Und weil man das auch absichtlich zerstörerisch einsetzen kann, hat Travis das an Security@Redhat geschickt. Fedora und Red Hat haben es bis heute ignoriert. Heute lief der Full-Disclosure Timer aus, mal sehen ob jetzt was passiert.

Für Grubunzulänglichkeiten können Red Hat und Fedora natürlich nichts, aber man muß ja nicht noch Öl ins Feuer kippen. Vor F30 wurde es mit mit pkexec ausgeführt, was sich besser auf bestimmte Prozesse oder Benutzer einschränken läßt. Warum das geändert wurde bleibt in einer dunklen Developer-Mailingliste verborgen 😉

 

 

Autorenlesung: „JA! Leben DARF leicht sein!“

Am 4. Dezember 2019 findet im „Vienna House Easy“ um 18 Uhr die Autorenlesung von Miriam Fuchs zu Ihrem neuen Buch „JA! Leben DARF leicht sein!“ statt.

Die Goslarsche Zeitung attestiert dem Werk, daß es eine grammatikalisch schmerzhafte Erfahrung darstellt, auch wenn man das anvisierte Geschlecht hat. Wobei das beim derzeitigen GenderInnen*wahn nicht viel zu sagen hat, denn es geht gar nicht um Genderismus, sondern um die Leichtigkeit des Seins an sich 🙂

Da ich Miriam kenne, dürfte der Abend unterhaltsam werden 🙂  Um 18 Uhr geht es los, der Eintritt ist frei.

Die Lokalität könnt Ihr hier finden:

Vienna House Easy Braunschweig

Salzdahlumer Str. 137
38126 Braunschweig
38126 Brunswiek
Lesungs-Termine
 26.11.19, 19 Uhr, HKK Hotel Wernigerode ****, Wernigerode
 04.12.19, 18 Uhr, Vienna House Easy, Braunschweig
 11.12.19, 15.30 Uhr, Regionalladen Quedlinburg
 12.12.19, 18.30 Uhr, black & white Optik Goslar

 2020:
 03.01.20, 19 Uhr, Neues Schützenhaus Osterode
 11.01.20, 18.30 Uhr, Antik Café Marie-Luise, Wildemann
 31.01.20, 19 Uhr, Schäfers Hof Osterwieck
 19.03.20, 19 Uhr, Stadtbibliothek "Heinrich Heine" (Eintritt 3 Euro)
 11.09.20, 19.30 Uhr, Leewer Däle, Liebenburg