Category Archives: Fedora

Wenn Grub nicht mehr bootet

Posted on by

Manchmal haben Bugs eine Geschichte und die Geschichte dieses Grubbugs wird heute erzählt werden.

Wenn Grub nicht mehr bootet

Damit der Eintrag nicht zu lang wird, gibt es nur die Highlights. Nehmt einfach an, daß da noch viel mehr in Spiel war 😉

Vor ein paar Jahren stellte ich auf meinem Fedora Surface Tablet fest, daß trotz dessen, daß neue Kernels installiert wurden, diese nicht im Bootmenü angezeigt wurden bzw. der gewählte Bootkernel nicht benutzt wurde, dafür waren uralte Einträge da drin bzw. nahm er immer den ersten Kernel.

Weil es eine recht neue Installation und das Gerät ein UEFI Bios hatte, wurde eine EFI Partition angelegt und eingebunden, ganz so, wie das sein muß. Auf dieser EFI Partition wird vom OS, hier Fedora, ein passender Ordner angelegt und u.a. der BootShim hingelegt:

[root@surface fedora]# ls -la /boot/efi/EFI/fedora/
insgesamt 17654
drwx------. 3 root root 2048 20. Sep 18:03 .
drwx------. 4 root root 2048 19. Jul 2023 ..
-rwx------. 1 root root 112 19. Mär 2024 BOOTIA32.CSV
-rwx------. 1 root root 110 19. Mär 2024 BOOTX64.CSV
drwx------. 2 root root 2048 4. Apr 19:36 fonts
-rwx------. 1 root root 2960704 12. Apr 01:00 gcdia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 gcdx64.efi
-rwx------. 1 root root 6523 3. Okt 2020 grub.cfg
-rwx------. 1 root root 6699 3. Okt 2020 grub.cfg.bak
-rwx------. 1 root root 7414 6. Nov 2022 grub.cfg.rpmsave
-rwx------. 1 root root 1024 3. Okt 2020 grubenv.bak
-rwx------. 1 root root 1024 4. Apr 19:08 grubenv.rpmsave
-rwx------. 1 root root 2960704 12. Apr 01:00 grubia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 grubx64.efi
-rwx------. 1 root root 673992 19. Mär 2024 mmia32.efi
-rwx------. 1 root root 848080 19. Mär 2024 mmx64.efi
-rwx------. 1 root root 949424 19. Mär 2024 shim.efi
-rwx------. 1 root root 747681 19. Mär 2024 shimia32.efi
-rwx------. 1 root root 949424 19. Mär 2024 shimx64.efi

Wie man sehen kann, liegt hier eine grub.cfg und eine grubenv , diverse Backups durch RPM und mich rum. Die gleichen Dateien findet man unter /boot/grub2/ auch nochmal, dort gehören Sie aber eigentlich auch hin.

Damals passierte folgendes

GRUBBY schrieb die Änderungen der Bootreihenfolge nach /boot/grub2/grubenv , aber GRUB lud die grubenv von /boot/efi/EFI/fedora/grubenv. Das ist die Quintessenz einer langen Investigation.

Die ganze Geschichte war etwas komplizierter, wie man in Bug #1625124 sehen kann.

Die Lösung war damals einfach: eine der Dateien mußt zur Anderen verlinkt werden.

ln -s /boot/efi/EFI/fedora/grubenv /boot/grub2/grubenv 

Damit waren beide immer in Sync und das von GRUB selbst geschaffene Problem, zwei verschiedene Orte zu benutzen, behoben. Jahrelang blieb der Fix bestehen und das mittlerweile auf Fedora 39 aktualisierte Tablet bootete immer korrekt.. bis diesen Montag 🙁 Da bootete es nicht mehr.

Stattdessen kam nur die GRUB-Shell. Alles reinstallieren vom GRUB-Bootloader, Konfig neu bauen half nichts.Ergo war das ein Fall für Linux am Dienstag, bei dem wir ganz praktisch das Problem besprochen, analysiert, gescheitert und dann final erfolgreich waren \o/

Was war passiert?

Am Wochenende waren Updates eingespielt worden, auch von Kernels und Grub. Was keiner dem Benutzer und damit dem Patch erzählt hat war der Umstand, daß das GRUB Team den 6 Jahre alten Problemfall behoben hat:

[root@surface fedora]# ls -la /boot/efi/EFI/fedora/
insgesamt 17654
drwx------. 3 root root 2048 20. Sep 18:03 .
drwx------. 4 root root 2048 19. Jul 2023 ..
-rwx------. 1 root root 112 19. Mär 2024 BOOTIA32.CSV
-rwx------. 1 root root 110 19. Mär 2024 BOOTX64.CSV
drwx------. 2 root root 2048 4. Apr 19:36 fonts
-rwx------. 1 root root 2960704 12. Apr 01:00 gcdia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 gcdx64.efi
-rwx------. 1 root root 159 20. Sep 18:03 grub.cfg
-rwx------. 1 root root 6699 3. Okt 2020 grub.cfg.bak
-rwx------. 1 root root 7414 6. Nov 2022 grub.cfg.rpmsave
-rwx------. 1 root root 1024 3. Okt 2020 grubenv.bak
-rwx------. 1 root root 1024 4. Apr 19:08 grubenv.rpmsave
-rwx------. 1 root root 2960704 12. Apr 01:00 grubia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 grubx64.efi
-rwx------. 1 root root 673992 19. Mär 2024 mmia32.efi
-rwx------. 1 root root 848080 19. Mär 2024 mmx64.efi
-rwx------. 1 root root 949424 19. Mär 2024 shim.efi
-rwx------. 1 root root 747681 19. Mär 2024 shimia32.efi
-rwx------. 1 root root 949424 19. Mär 2024 shimx64.efi

Achtet mal auf die Größe der grub.cfg : 159 Bytes

Das steht drin:

# cat /boot/efi/EFI/fedora/grub.cfg
search –no-floppy –root-dev-only –fs-uuid –set=dev 0669a2db-8ba9-4054-a629-cd7cf2eb12c8
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg

Man hat also endlich nur noch einen Ort für die Grub.cfg nämlich /boot/grub2/grub.cfg . Die im EFI Ordner ist jetzt nur noch ein Wrapper, der die eigentliche grub.cfg einbindet, so muß man nur noch eine erzeugen und bleibt rückwärtskompatibel, außer, man hatte das Problem selbst bereits gelöst, dann landete man in der GRUB-Shell, weil …

Wenn die GRUB-Config gebaut wird, wird zuerst der kurze Wrapper /boot/efi/EFI/fedora/grub.cfg erzeugt, DANN erst die /boot/grub2/grub.cfg geschrieben.

Wenn aber /boot/grub2/grub.cfg ein LINK auf /boot/efi/EFI/fedora/grub.cfg ist, dann wird die kurze Fassung durch die Hauptkonfig ersetzt und nagelt dabei den Prefix für das Bootdevice weg. Als Folge kann Grub die Bootpartition nicht mehr finden und bootet nicht mehr.

Lösung:

rm -f /boot/grub2/grub.cfg /boot/grub2/grubenv
grub2-mkconfig > /boot/grub2/grub.cfg
grub2-install –force –target=x86_64-efi /dev/nvme0n1 ( in meinem Fall)

Danach war /boot/efi/EFI/fedora/grub.cfg wieder normal und das System hat endlich wieder gebootet.

Dank nochmal an alle die gestern Abend bei Linux am Dienstag geholfen haben, das war knifflig, aber genau dafür machen wir diese Videokonferenz: Linux basteln 😀

Krita, Fedora und die neue PreAlpha 5.3.0

Posted on by

Krita Freund aufgepaßt, es tut sich was im Fedoraländle 😉 Dazu werfen wir noch einen Blick auf die neue 5.3.0 von Krita.

Krita, Fedora und die neue PreAlpha 5.3.0

Seit einigen Jahren schon, wird Krita auf Fedora nicht mehr so gepflegt, wie man sich das gewünscht hat. Beim Wechsel von 4.x auf 5.0 funktionierte G’mic nicht mehr, das wohl mit Abstand beste Filter & Effektprogramm jenseits von Photoshop. Bis heute war kein Update für Fedora in der Lage G’mic, das in Krita 5.0 implementiert wurde, funktionsfähig zu präsentieren. Ich habe dazu seit Jahren einen Bug auf im Tracker.

RDieter, der bisherige Maintainer von Krita und Fedora, hat sich vor ein paar Tagen von Krita für Fedora zurückgezogen und die Extras-Orphan Gruppe hat übernommen. Das war kein gutes Zeichen für Krita unter Fedora, daher auch die entsprechende Trauermeldung beim letzten Linux am Dienstag… glücklicherweise etwas verfrüht, denn Krita lebt noch. Niel Gompta hat das Paket unter seine Fittiche genommen.

Ich hoffe, daß er es endlich hinbekommt G’Mic mit zu kompilieren. Wie das mit Krita so aussieht, schauen wir uns bei der PreAlpha 5.3.0 an, die kann man als AppImage laden und da geht es dann nämlich 😉

25 Jahre Krita

G’mic kommt mit 591 Filter daher

Diese Filter können alles, sogar ein Pinephone Foto entrauschen, und das ist mit Krita Bordmitteln nicht zu schaffen 🙂

Hier mal ein Beispiel von unserer Katze „Kurzschwanz“ ( siehe eigenes Blog ) und der 2D->3D Umwandlung 😉

Man sieht das Bild einer Katze mit der GMIC Filterliste. Der Filter Stereographie ist offen und im Detail zusehen.

G’Mic in Krita

und so sieht das Ergebnis aus:

3D-Bild von Kurzschwanz

Normalerweise braucht man dafür 2  Bilder, weil man den Unterschied farblich nutzt, aber G’Mic bekommt das auch mit nur einem Bild hin und wie gut, ist echt der Hammer 😀

Auch der Repairmodus für Flecken die beim Scannen oder schon bei der Aufnahme ins Bild gekommen sind, ist extrem nützlich.

Krita Download

Hier gibt es die Alphas und Betas von Krita für Linux:

https://cdn.kde.org/ci-builds/graphics/krita/master/linux/

Wer das AppImage starten will, sollte es als Ausführbar markieren, weil das sonst als Datei mit einem anderen Programm gestartet werden wird 😉 Einfach in Nemo, Nautilus etc. rechts Anklicken -> Eigenschaften -> Zugriffsrechte und Ausführbar machen. Und jetzt viel Spaß mit dem neuen Krita \o/

Alpaca, Ollama und wie man es missbrauchen kann

Posted on by

Seit letztem Dienstag bastel ich mit lokalen LLM rum. Dazu habe ich Alpaca ausprobiert, daß als Flatpak installiert wurde.

Alpaca, Ollama und wie man es missbrauchen kann

Das zuerst wählt man sich eins oder mehrere Sprachmodelle aus, die man benutzen will:UI Oberfläche mit einer Auswahl von Modellen in einer ListeDanach kann man direkt loslegen, weil Alpca als Frontend für Ollama alles nötige macht:

– Ollama als Dienst starten
– die Modelle vorbereiten und pullen
– eine Eingabeoberfläche mit HTML Ausgabe bereitstellen.

Wer jetzt nur mit dem Modell Spielchen treiben will, kann direkt anfangen. Wer aber ohne die Oberfläche jedes mal starten zu müssen, mit den Modellen interagieren möchte, der sollte Ollama selbst installieren.

Dazu einfach root werden und das Install Script starten. Wenn man bereits 3D-vollständige Grafikkarteninstallationen hat, passiert nicht viel, außer:

– Ollama User wird angelegt
– Systemd Service erstellt
– Ollama initialisiert

Mehr braucht es nämlich gar nicht. Das Ganze wird mit einer einzigen Zeile gestartet:

$ curl -fsSL https://ollama.com/install.sh | sh

Nach dem Start sieht das dann so aus:

$ systemctl status ollama
● ollama.service – Ollama Service
Loaded: loaded (/etc/systemd/system/ollama.service; enabled; preset: disabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Fri 2024-08-09 11:13:18 CEST; 6s ago
Main PID: 82811 (ollama)
Tasks: 18 (limit: 18994)
Memory: 1.7G
CPU: 8.917s
CGroup: /system.slice/ollama.service
└─82811 /usr/local/bin/ollama serve$ netstat -nlap|grep 114
…
tcp 0 0 127.0.0.1:11434 0.0.0.0:* LISTEN –
tcp 0 0 127.0.0.1:11435 0.0.0.0:* LISTEN 6638/ollama

Hmm, Zwei Ollama’s … ja klar, eins vom Flatpak und eins haben wir je gerade installiert.

Alpaca Daten übertragen

Weil das Vorbereiten der Modelle und das Pullen der Datenblobs nicht jedermans Sache ist, klauen wir uns jetzt die Daten vom Flatpak und schieben es der eigenen Installation unter 😀 Alpaca beendet man jetzt am besten

$ ls -la .var/app/com.jeffser.Alpaca/data/
insgesamt 24
drwxr-xr-x. 5 marius marius 4096 9. Aug 11:07 .
drwxr-xr-x. 7 marius marius 4096 6. Aug 09:34 ..
drwxr-xr-x. 2 marius marius 4096 7. Aug 15:59 chats
drwx——. 3 marius marius 4096 6. Aug 09:34 .nv
drwxr-xr-x. 3 marius marius 4096 8. Aug 13:35 .ollama
-rw-r–r–. 1 marius marius 280 9. Aug 11:07 tmp.log

 

$ su root
$ systemctl stop ollama
$ mv /usr/share/ollama/.ollama /usr/share/ollama/.ollama.old
$ mv /home/$USER/.var/app/com.jeffser.Alpaca/data/.ollama /usr/share/ollama
$ chown ollama: -R /usr/share/ollama/.ollama
$ systemctl enable -now ollama

Fertig. jetzt könnt Ihr direkt mit den installierten Modellen arbeiten und braucht keine GUI mehr. Das erlaubt unserer Freundin Carola jetzt Ollama direkt auf Port 11434  anzusprechen und Ihre Fähigkeiten zu erweitern 😉

WARNUNG:

Diese Sprachmodelle sind riesig und werden komplett in den Speicher geladen. Unter 16 GB Ram geht da gar nichts, weil Carolas STT Dienst ja auch schon 3,2 GB Ram haben will und die Modelle meisten größer als 5 GB sind.

Wie das alles genau geht, gibt es nächstes Linux am Dienstag 😉

Als kleine Vorschau, was Euch qualitativ so erwartet, wenn Ihr den Kram lokal bei Euch laufen lasst, hier ein Bericht von einem „KI“-Assistenten-Gadget, von dem ich genau weiß, was es getan hat :DDD

Wer dagegen lieber live bei der Zerstörung von „KI“ dabei ist, der ist besser nächste Woche Dienstag um 19 Uhr bei Linux am Dienstag dabei :DDD

Wer mal bewusst gekauftes Sponsering für ein Produkt erleben möchte, der schaut sich zum Rabbit R1 das mal an:

„gekauft“, weil das Teil so schlecht ist, daß das unmöglich nicht aufgefallen sein kann 😉