Solus 4.8

[Caramon2]

Vorab eine Warnung:

Wie sich in #16 gezeigt hat, ist der Bootloader von Solus über 100 MiB groß und damit sogar größer als die ganze ESP von Windows 11 (was dort schon 32 MiB belegt): Dadurch kam es zu dem beschriebenen Installations-Fail.

Falls ihr Solus trotz der Probleme, auf die ich von Anfang an stieß (wer weiß was da noch alles kommt…), installieren wollt, müsst ihr vorher prüfen, ob auf der ESP überhaupt genug Platz dafür frei ist: Solus macht das nicht!

Nachtrag:

Nachdem ich Solus neben der neuen Windows 11 Installation mit der 1 GiB ESP (s. u.) installiert habe, wurde der Bootloader zwar installiert, aber beim Reboot bootete Solus direkt: Es gab kein Boot-Menü mit Windows!

Ich kontrolliere "/etc/default/grub": 5 Sek. Timeout und der os-prober war auch nicht deaktiviert, also sudo update-grub: Fehlermeldung: "/boot/grub/grub.cfg.new" würde nicht existieren.

1. ist das sowieso der falsche Name, 2. existierte das ganze Verzeichnis "/boot/grub/" nicht und 3., wurde die ESP gar nicht erst in /boot/grub/efi/ eingehängt!

WAS FÜR EIN SCHROTT !!!!!!!!!​

Ich habe die Schnauze voll: Solus wird platt gemacht, das ISO gelöscht und ich rühre diesen Mist nie wieder an. Punkt!

---

Ein kleiner Erfahrungsbericht

Da gestern Solus 4.8 freigelassen wurde, inzwischen Calamares als Installer nutzt und Xfce keinen Beta-Status mehr hat, wollte ich es mir seit langem mal wieder ansehen und es testweise neben meinem im UEFI-Modus installiertes Test-Windows 11 (nur installiert und bereinigt, nichts weiter geändert) installieren:

Aber:

Die ESP sieht normal aus:

Aber es wird nur hierhin gebootet:

Im UEFI gibt es zwar einen Solus-Eintrag, aber der führt nur wieder zu obigen:

Windows 11 bootet noch, wobei es egal ist, ob ich den Eintrag im Bootmenü oder im UEFI verwende.

Als Gegenprobe habe ich Artix installiert (wieder von der unveränderten Grund-Windows-Installation - s. Link oben), da das auch den Calamares-Installer nutzt, aber an dem liegt es offenbar nicht, da das problemlos funktioniert hat:

(das ist die Xfce-Standardkonfiguriation: so nutze ich es stattdessen )

Schade.

Bevor Solus vor einigen Jahren fast eingestampft wurde, machte es auf mich einen sehr guten Eindruck und ich habe es empfohlen: Als stabiles Rolling-Release müsste nie eine neue Version installiert werden und der Budgie-Desktop sehr einsteigerfreundlich und komfortabel war.

Ich dachte, inzwischen hätten die sich von dem Crash erholt, aber nach diesem Ersteindruck (wer weiß was noch "kaputt" ist), bleibe ich lieber bei LMDE als Empfehlung für Einsteiger. - Das Upgrade vom 6 auf 7 war für mich zwar mit einigen Ärgernissen verbunden, hat dann aber zuverlässig funktioniert.

Btw:

Ich habe den Thread zur Info erstellt, weil es hier schon lange nichts mehr zu Solus gab.

Als nächstes werde ich es auf der ext.-SSD vom letzten Link installieren, um es noch eine Zeit lang zu beobachten. Da das im BIOS-Modus ist, wird es vermutlich keine Probleme geben, oder sie leicht lösbar sein: Im Gegensatz zu UEFI ist der BIOS-Modus unkompliziert und zuverlässig.

 

[Caramon2]

Als nächstes werde ich es auf der ext.-SSD vom letzten Link installieren, um es noch eine Zeit lang zu beobachten. Da das im BIOS-Modus ist, wird es vermutlich keine Probleme geben

Obwohl ich es auf xfs installiert habe (früher funktionierte ausschließlich auf ext4: Auf anderen Dateisystemen streikte das Solus-Pendant zu "update-grub" (irgendwas mit clr-bootmanager, oder so) und es war nicht mehr bootfähig), hat es auf Anhieb funktioniert (interessanteweise hat auch mein Artix den Kernel 6.17.8, wie auch LMDE 7 den 6.17.8 gestern als Backport bekommen hat):

Obwohl Xfce auf GTK aufsetzt, war Discover (QT) als Software-Center installiert - und hat gleich einen extrem schlechten Eindruck gemacht:

Zuerst mal war die Anzeige riesengroß (und nur einspaltig), es passten gerade mal 5 oder 6 Anwendungen untereinander, es gab keine Möglichkeit auf eine Art Listenansicht, oder Kompakt umzuschalten und die Einstellmöglichkeiten als "mager" zu bezeichnen, wäre noch extrem beschönigend.

Dann wollte ich den Discover-Flatpak-Support deinstallieren und es hagelte haufenweise Fehlermeldungen, von wegen keine ausreichenden Rechte: Das Passwort wurde vorher aber abgefragt.

Nachdem endlich keine Fehlermeldungen mehr kamen, habe ich Discover beendet und mich im Terminal als root angemeldet (sudo -i), um mit "eopkg" (das "apt" von Solus) weiterzumachen und wurde positiv überrascht: Das ist richtig schnell geworden!

Früher war es sogar noch deutlich langsamer als "apt" (wirklich elend zäh), aber z. B. eopkg li (list installed) war jetzt in knapp 3 Sekunden durch: Früher hat das 2 Minuten gebraucht! Auf dem selben Rechner! - Deshalb hatte ich die Ausgabe in eine Textdatei umgeleitet, um per "grep" oder "less" vernünftig damit arbeiten zu können.

Ich habe Firefox, Thunderbird und Libreoffice deinstalliert (als Funktionstest und weil ich es sowieso nicht brauche) und mit eopkg rmo anschließend noch die verweisten Abhängigkeiten: Das sah sauber aus, also keine auffälligen Dateileichen. Dann wollte ich mit eopkg up aktualisieren (quasi pacman -Syu), aber es gab noch keine Updates.

Ach ja, fast vergessen: Als ich mit eopkg Discover deinstallieren wollte, wurde es nicht gefunden und war auch nicht mehr im Startmenü: Dieser glorreiche Tool ("glorreich" verwende ich sonst nur in Verbindung mit Microsoft) hat sich offenbar selbst entsorgt, als ich nur das Flat-Plugin deinstallieren wollte: Ohne jegliche Warnung, oder dass auch nur aufgelistet wurde, was als Anhängigkeiten mit entfernt wird!

Naja. Damit hätte ich eigentlich schon alles durch und könnte es gleich runterschmeißen: Was soll ich noch beobachten?

Aber ich lasse es erst mal auf der SSD, vielleicht ergibt sich ja noch was. - Z. B. habe ich es noch nicht nativ gebootet und ich könnte noch ausprobieren, ob Solus inzwischen mit meinem Drucker (Brother HL-2030) klar kommt: Damals hatte es immer einen falschen CUPS-Treiber genutzt und wenn ich was gedruckt habe, lief der Drucker kurz an, ging dann wieder in den Ruhezustand und Solus war der Meinung, er hätte erfolgreich gedruckt.

Ich hatte versucht den richtigen CUPS-Treiber von Manjaro zu übernehmen (hatte ich damals auch als Testinstallation), ich konnte ihn bei Solus auch "erfolgreich" einbinden, aber damit lief der Drucker noch nicht mal an.

 

[Caramon2]

ob Solus inzwischen mit meinem Drucker (Brother HL-2030) klar kommt: Damals hatte es immer einen falschen CUPS-Treiber genutzt und wenn ich was gedruckt habe, lief der Drucker kurz an, ging dann wieder in den Ruhezustand und Solus war der Meinung, er hätte erfolgreich gedruckt.

Es wird immer noch der falsche Drucker-Treiber gewählt, aber wenn ich drucken will, stürzt schon der Druck-Dialog ab: Es öffnet sich nur die Fensterumrandung mit Schatten, aber ohne Inhalt (also transparent), weiter passiert nichts. Es lässt sich auch nicht schließen und nach ein paar Versuchen wird gefragt, ob es abgeschossen werden soll.

Hier der genutzte Treiber und die Auswahl:

Und das ist installiert, bzw. wird in den Paketquellen zu cups gefunden:

…

Hier zum Vergleich die Auswahl bei einer standardmäßigen LMDE-7-Installation (neulich frisch installiert und seit dem aktuell gehalten: Mit cups/Drucker hatte ich bisher noch gar nichts gemacht). Ich habe extra darauf geachtet, dass die Scrollbalken gezeigt werden:

Nachtrag: Ein weiterer Unterschied war, dass mit eingeschaltetem Drucker bei LMDE nach dem booten gleich die Meldung kam, dass er gefunden und eingerichtet wurde, während bei Solus nicht passierte und auch die Druckereinstellung leer blieb: Ich musste ihn manuell hinzufügen, wobei er dann zwar automatisch als USB-Drucker erkannt wurde, aber eben der falsche Treiber "empfohlen" wurde und es den richtigen nicht mal gab.

Auch diesbezüglich ist LMDE besser für Einsteiger geeignet.

Mein Fazit:

Für jemanden, der einfach nur seinen PC nutzen möchte, wäre Solus toll, weil es als stabiles rolling Release nur gelegentlich aktualisiert werden muss. Aber da es schon an sowas trivialem wie eine ausreichende Drucker-Unterstützung *) scheitert (vom Installations-Fail parallel zu Windows ganz zu schweigen, oder dass sich Discover ohne Hinweis und Warnung, aber mit vielen Fehlermeldungen, ohne Möglichkeit abzubrechen, selbst entfernt - wie schnell kann man sich damit versehentlich das System zerschießen…), ist es nicht empfehlenswert.

*) selbst für Brother-Drucker, obwohl ich mir den extra ausgewählt habe, weil Brother damals (2007) schon guten Linux-Support hatten: Mit Linux hatte ich noch nichts am Hut, aber nach dem Mist mit meinem CanoScan N1220U (nach XP 32 Bit gab es keine neuen Treiber mehr: um unter Windows scannen zu können, hatte ich mein altes XP-Home in Virtualbox installiert), hatte ich mir gedacht: Wenn die sogar Linux unterstützen, wird es bei Windows erst recht keine Treiberprobleme geben.

 

[Uridium]

Ich benutze den proprietären Brother Treiber, weil das der einzige ist, bei dem der 1200dpi Modus funktioniert. 'Gutenprint' habe ich auch nie zum Laufen bekommen.

 

[Caramon2]

Ich nutze bei Artix den brother-hl2030 aus dem AUR, da der Treiber, den CUPS standardmäßig nutzt, beim Ausdruck nach jeder Seite eine kurze Pause gemacht hat.

Der brlaser, den LMDE 7 jetzt nutzt, ist mir vorher noch nie aufgefallen. Wie der sich bei mehrseitigen Ausdrucken verhält, habe ich noch nicht getestet. - Solus hat den übrigens auch in den Paketquellen. Das werde ich noch testen.

früher funktionierte ausschließlich auf ext4: Auf anderen Dateisystemen streikte das Solus-Pendant zu "update-grub" (irgendwas mit clr-bootmanager, oder so) und es war nicht mehr bootfähig

Das Problem gibt es definitiv nicht mehr:

Ich habe Solus per rsync -vaxH gesichert, die Partition mit der selben UUID auf btrfs+zstd umformatiert (mit der normalen Verzeichnisstruktur, also ohne diesen @-Kram), Sicherung zurück, grub.cfg und fstab angepasst, gebootet: Funktioniert. (den Bootloader stellt inzwischen wieder LMDE, so dass ich auch dessen grub.cfg anpassen musste, aber nicht grub neu installieren brauchte)

Anschließend habe ich Plymouth deinstalliert, wodurch automatisch der clr-boot-manager ausgeführt wurde (eine Kombination aus update-grub und update-initramfs): Es gab keine Fehler und es bootete weiterhin.

Außerdem wird inzwischen zRAM unterstützt (früher hatten die das Modul sogar aus ihren Kerneln entfernt!), so dass es zum Experimentieren insgesamt viel besser geeignet ist, aber aufgrund der ganzen Ecken und Kanten eben nichts für Otto*in Normalo, der/die/das den PC einfach nur nutzen möchte. - Wofür es als stabiles rolling Release eigentlich prädestiniert wäre: Irgendwie absurd, da zum Experimentieren Distros wie Arch, oder Gentoo weit besser geeignet sind.

Also für das, was es kann, wäre es alles andere als meine erste Wahl (das fängt schon damit an, dass es für Xfce nicht mal die CPU-Last- und Systeminfo-Plugins gibt - und auch sonst fehlt vieles: Die spärliche Auswahl, wie bei den Druckern, zieht sich durch's gesamte System) und das wofür es meine erste Wahl wäre (eine sehr pflegeleichte Distro, die man einmalig DAUs einrichten kann und sich dann nicht mehr drum kümmern muss), kann es nicht.

Wirklich schade. - Als ich Anf. 2020 nach einer Alternative zu LinuxMint suchte und auf Solus gestoßen bin, machte es einen sehr guten Eindruck und zeigte viel Potenzial: Hätte es da schon Xfce gegeben (man konnte es nicht mal nachinstallieren und die Macher sagten ausdrücklich: Xfce wird es nie für Solus geben, man kann stattdessen MATE nutzen), wäre ich vermutlich darauf umgestiegen.

 

[Uridium]

Ich nutze bei Artix den brother-hl2030 aus dem AUR

Ja, den meine ich. Die HL-2030/40 haben außergewöhnliche GDI Treiber. Das Bild wird im PC vorgerendert, komprimiert und zum Drucker gesendet. Dafür braucht das Gerät dann nur 8MB RAM. Für Lasergeräte ist das unüblich.
Irgendwann geht der Papiereinzug kaputt.

 

[Caramon2]

Update:

Ein weiterer Unterschied war, dass mit eingeschaltetem Drucker bei LMDE nach dem booten gleich die Meldung kam, dass er gefunden und eingerichtet wurde, während bei Solus nicht passierte und auch die Druckereinstellung leer blieb: Ich musste ihn manuell hinzufügen, wobei er dann zwar automatisch als USB-Drucker erkannt wurde, aber eben der falsche Treiber "empfohlen" wurde und es den richtigen nicht mal gab.

Wenn ich den "brlaser" (den gibt es übrigens auch im Chaotic-AUR) installiert habe, ändert sich daran zwar nichts, aber es wird dann der richtige Treiber genutzt (die Seite mit der Druckerauswahl erscheint gar nicht erst - in #3 der 2. Screenshot) und es gibt auch HQ1200 (habe ich nicht getestet):

Ich habe mit LibreOffice vier leere Seiten drucken lassen: Die wurden damit ohne Pause durchgezogen.

Das könnte eine Alternative zum "brother-hl2030" aus dem AUR sein, da bei dessen Installation immer angezeigt wird (sinngemäß - ich kann es gerade nicht reproduzieren), dass der eine veraltete Schnittstelle nutzt, die bald nicht mehr von CUPS unterstützt wird.

Der "brlaser" wurde übrigens schon bei CommodoreOS 2.0 (basiert auf Debian 11 von 2021) verwendet. - Ganz früher, der mit der Pause zwischen den einzelnen Seiten, wurde als "hl-1250" (oder so - ältere Livesysteme habe ich leider nicht mehr) angezeigt.

 

[Uridium]

Den hl-1250 kenne ich. Der kann nur 600dpi. Bei 1200dpi macht er Blödsinn. 'Brlaser' sagt mir gerade nichts, werde ich aber testen.

 

[Caramon2]

Das könnte eine Alternative zum "brother-hl2030" aus dem AUR sein, da bei dessen Installation immer angezeigt wird (sinngemäß - ich kann es gerade nicht reproduzieren), dass der eine veraltete Schnittstelle nutzt, die bald nicht mehr von CUPS unterstützt wird.

Das ist es:

Printer drivers are deprecated and will stop working in a future version of CUPS. See https://github.com/OpenPrinting/cups/issues/103

---

Den hl-1250 kenne ich. Der kann nur 600dpi. Bei 1200dpi macht er Blödsinn. 'Brlaser' sagt mir gerade nichts, werde ich aber testen.

Ich bin jetzt komplett umgestiegen und habe endlich ein reines 64-bit-System:

# pacman -Qs cups
local/cups 2:2.4.15-1
    OpenPrinting CUPS - daemon package
local/cups-filters 2.0.1-2
    OpenPrinting CUPS Filters
local/cups-runit 20180226-3 (runit-world)
    runit service scripts for cups
local/libcups 2:2.4.15-1
    OpenPrinting CUPS - client libraries and headers
local/libcupsfilters 2.1.1-2.1
    OpenPrinting CUPS Filters - contains all the code of the filters of the former cups-filters package as library functions
local/python-pycups 2.0.4-3
    Python bindings for libcups
local/system-config-printer 1.5.18-5
    A CUPS printer configuration tool and status applet

# pacman -Qs printer
local/brlaser 6.2.8-1
    Brother laser printer driver
local/system-config-printer 1.5.18-5
    A CUPS printer configuration tool and status applet

# pacman -Qs lib32

# _

 

[Caramon2]

@All: Da alle Distributionen das gleiche CUPS nutzen, gilt alles dazu auch für Solus. - Das ist also kein OT.

@Uridium: Als ich gestern “brlaser“ bei Artix testen wollte, dachte ich zuerst ich hätte mein CUPS zerschossen, da der sich cupsd nicht mehr starten ließ. … Aber auch nachdem ich die Sicherung von vor den Tests wiederhergestellt hatte, war das noch so. Erst bei der Sicherung von Samstag funktionierte es wieder: Seit dem war CUPS von 2.4.14 auf 2.4.15 aktualisiert worden. - Wie ich inzwischen herausgefunden habe, passiert das auch bei anderen Distributionen.

Den Grund lieferte:

# cupsd -t
Unknown directive IdleExitTimeout on line 32 of /etc/cups/cupsd.conf.
"/etc/cups/cupsd.conf" contains errors.

was das war:

# Timeout after cupsd exits if idle (applied only if cupsd runs on-demand - with -l)
IdleExitTimeout 60

Nachdem ich "IdleExitTimeout 60" auskommentiert hatte, ließ cupsd sich wieder starten.

Das ist wieder so ein typischer, dämlicher Zufall: Man ändert was und etwas unmittelbar damit zusammenhängendes funktioniert nicht mehr, aber das hat dann trotz der offensichtlichen Kausalität überhaupt nichts miteinander zu tun…

Deshalb habe ich "system-config-printer" installiert: Als ich obiges endlich hinbekommen hatte und dann localhost:631 öffnete, um den neuen Druckertreiber einzurichten, wurde es mir zu viel, da ich mich dort erst wieder hätte zurechtfinden müssen.

Btw:

Ich habe übrigens auch keine linux-headers und kein dkms installiert: Mein System ist also auch in anderer Hinsicht "rein".

 

[Caramon2]

Weil ich es schon etwas zerbastet hatte, habe ich Solus nochmal frisch installiert und als erstes ausgemistet:

"system.base" ist die Paketdatenbank: Ich hatte die noch nicht aktualisiert und Solus hat offenbar keine vorinstalliert. Nach eopkg up (wie obiges als root) gab es die Meldung nicht mehr. - Allerdings immer noch keine Aktualisierungen, weshalb es u. a. noch CUPS 2.4.14 nutzt.

Anschließend habe ich "brlaser", "mpv", "yt-dlp", "gnome-disks", "gnome-syterm-monitor" und "gnome-Web" installiert, um ein grundlegend brauchbares System zu bekommen.

Auch eine Sicherung habe ich mir dafür erstellt (einfach das Skript von LMDE genommen und "LMDE" durch "Solus" ersetzen lassen - s. 2. Screenshot in #2):

#!/bin/bash
ns=Solus  # Name der zu sichernden Partition (darf keine Leerzeichen oder Steuerzeichen enthalten)
zs=4      # Anzahl der Sicherungsstufen

# die Quell-Partition einhängen, falls noch nicht gemacht (Abbruch bei Fehler):
if [ ! -d /run/media/$USER/"$ns" ]
 then udisksctl mount -b /dev/disk/by-label/"$ns" || exit
fi

# Die Sicherungsstufen neu durchnummerieren:
espeak-ng -vde -a50 "Bitte Passwort" & sudo mv "$ns"_$zs "$ns"_A 2>/dev/null

for ((z=$zs;z>=0;z--))
 do mv "$ns"_$z "$ns"_$((z+1)) 2>/dev/null
done

if [ ! -d "$ns"_A ]
 then mkdir "$ns"_0
 else mv "$ns"_A "$ns"_0
fi

# Sicherung durchführen und dem Verzeichnis das aktuelle Datum geben:
sudo rsync -vaxH --del --link-dest=../"$ns"_1/\
 --exclude '.cache/*' --exclude '/tmp/*' --exclude '/media/*' --exclude '/var/tmp/*' --exclude '/var/log/*' --exclude '*.log' --exclude '*.old' --exclude '*_old'\
 /run/media/$USER/"$ns"/ "$ns"_0/ && sudo touch "$ns"_0
sync -f .

espeak-ng -vde -a50 "Datensicherung abgeschlossen" & read -p "[Enter]"

"Solus_1" gab es beim ersten Durchlauf natürlich noch nicht, aber ab dem nächsten spart es richtig was, da unverändertes als Hardlinks übernommen werden.


Wichtig für das Skript:

Es funktioniert nur von einem anderen System aus (auch von einem Livesystem), das zu sichernde System muss auf einer einzigen Partition installiert sein und darf keinen @-Snapshot-Kram nutzen (damit ärgere ich mich nicht mehr herum), wobei darauf geachtet werden muss, wo externe Partitionen einhängt werden:

Bei Artix und Solus in /run/media/$USER/[Partitionsname] (/run/ ist eine RAM-Disk), während z. B. Debian- und Ubuntu-Derivate es immer noch direkt auf die Systempartition schreiben: /media/$USER/[Partitionsname] - Das muss im Skript entsprechend angepasst werden.

Wie schon geschrieben, kann der Namen ("LMDE", "Solus", usw.) beliebig geändert werden, er darf aber keine Leerzeichen oder Steuerzeichen enthalten. - Ich mache das generell nicht, weshalb das Skript nicht darauf ausgelegt ist.

Das Skript kommt dorthin, wohin gesichert werden soll (in einem beliebigen Verzeichnis auf einem beliebigen Datenträger (natürlich sollte dort genug frei sein) und wenn es ausgeführt wird, werden dort die Sicherungen erstellt:

In diesem Fall immer in "Solus_0", was bei der nächsten Ausführung in "Solus_1" umbenannt wird und in ein neu erstelltes "Solus_0" gesichert wird, usw. - Bis die max. Anzahl der Sicherungsstufen erreicht ist: Dann wird das jeweils letzte Verzeichnis in "Solus_0" umbenannt und aktualisiert.

So ist "Solus_0" immer die aktuellste Sicherung und die anderen die jeweils folgenden, wobei das Datum der Verzeichnisse der jeweilige Sicherungszeitpunkt ist.

Die Anzahl kann man auch nachträglich beliebig erhöhen, aber wenn man sie reduziert, muss man die dann überzähligen Stufen manuell löschen, da das Skript sie nur nicht mehr berücksichtigt, aber nicht automatisch löscht.

Zur Wiederherstellung einfach wieder von einem anderen System aus Sicherungspartition und Zielpartition einhängen und auch per rsync übertragen (die Pfade natürlich anpassen):

sudo rsync -vaxH --del [Quellpfad] [Zielpfad]

 

[Caramon2]

Solus hat inzwischen auch CUPS 2.4.15 bekommen, aber das hat kein Problem mit der betreffenden Zeile.

Bei Artix gab es auch ein Update (von 2.4.15-1 auf 2.4.15-2), aber am Bug hat das nichts geändert. Im Artix-Forum haben den schon mehrere gemeldet.

Nachtrag: Auch cups 2.4.15-3 aus "gremlin" (sozusagen "testing") soll den Bug noch haben.

 

[Caramon2]

Obwohl Xfce auf GTK aufsetzt, war Discover (QT) als Software-Center installiert - und hat gleich einen extrem schlechten Eindruck gemacht:

Um zu zeigen, wie ineffizient das ist, hier ein Vergleich der Download-Größe (installiert sind es natürlich deutlich mehr):

Gnome-Software ist zwar auch wie für Grobmotoriker gemacht (mich erinnert solche Software an Playmobil im Vergleich zu Lego), erscheint mit aber eingängiger. - Und vor allem werden keine Abhängigkeiten angezeigt, die wer weiß was mitreißen, wenn man sie deinstalliert.

Also für Einsteiger wäre das vermutlich sowieso die bessere Wahl.

Btw:

Ich habe das Sicherungsskript in #11 etwas vereinfacht und dokumentiert.

 

[Uridium]

Nachdem ich "IdleExitTimeout 60" auskommentiert hatte, ließ cupsd sich wieder starten.

Kurios...

$ sudo cupsd -t
Printer drivers are deprecated and will stop working in a future version of CUPS. See https://github.com/OpenPrinting/cups/issues/103
"/etc/cups/cups-files.conf" is OK.
"/etc/cups/cupsd.conf" is OK.
$ sudo cat /etc/cups/cupsd.conf
LogLevel warn
MaxLogSize 1m
ErrorPolicy stop-printer
Listen localhost:631
Listen /run/cups/cups.sock
Browsing Yes
BrowseLocalProtocols dnssd
DefaultAuthType Basic
WebInterface Yes
IdleExitTimeout 60
MaxJobs 100
PreserveJobFiles 14d
$ yay -Qs cups
local/cups 2:2.4.16-1
    OpenPrinting CUPS - daemon package

 

[Caramon2]

local/cups 2:2.4.16-1

Das ist nicht die 2.4.15-1 oder 2.4.15-2.

Bei Artix gab es die 2.4.16-1 knapp 2h später aber auch. *) … und cupsd startet jetzt wieder mit der Zeile. Obwohl sudo cupd -t sie hier immer noch als "unknown" anmeckert.

*) ich aktualisiere normalerweise nur Sonntags, da es dann am seltesten Probleme gibt. - Ich vermute, weil die Entwickler bis zum WE alles in trockenen Tüchern haben wollen und das "basteln" auf die nächste Woche verschieben.

 

[Caramon2]

Aber:

[IMG]https://www.computerbase.de/forum/attachments/solus-3-png.1680398/[/IMG]

Ich weiß jetzt wieso:

Windows 11 erstellt standardmäßig eine 100 MiB ESP und dafür ist der Solus-Bootloader zu groß!

Ich habe vor der Windows-Installation eine 1 GiB ESP erstellt (mehr nicht: Nur GPT-Partitionierung + 1 GiB ESP und den Rest leer gelassen) und als ich anschließend wie im Erröffnungsbeitrag Solus dazu installiert habe, hat es funktioniert.

Aber:

Wie dämlich ist das denn!?

1. Macht Windows 11 das "schon immer" so, also seit mehreren Jahren!
2. Weshalb wird das trotzdem nicht berücksichtigt?
3. Wieso wird nicht wenigstens vorher geprüft, ob die ESP groß genug ist?
4. Weshalb erhält man noch nicht mal eine konkrete Fehlermeldung? - Statt "…konnte nicht installiert werden" - obwohl ja was da war: s. o. - "Fehlercode 1" - ohne Verweis, wo man nachsehen kann, was das bedeutet…)
5. Wieso ist das Ding überhaupt so riesengroß? - Als ich bei meinem Artix mit UEFI experimentiert habe,waren das gerade mal 300 KB(!): Ich konnte die ESP ins 1 MiB vor der ersten regulären Partition quetschen! - Übrigens FAT12-formatiert.

Zumindest ist das konsequent: Das was Discover oben "verbrochen" hat, war ja der gleiche Murks. - Und das waren nur die Sachen, die mir gleich am Anfang aufgefallen sind: Wer weiß was für Überraschungen da sonst noch auf einen warten…

Mein erster Eindruck hat sich damit jedenfalls bestätigt: Nicht für Einsteiger geeignet, da zu viele potenzielle Stolperfallen.

Nachtrag:

Hier zum Vergleich der Bootloader von LMDE:

Und damit ihr seht, dass ich bei 5. nicht übertrieben habe, hier der von Artix:

Deshalb fand ich die 32 MiB, die Windows dort alleine für sich belegt, schon gigantisch!

Beides jeweils parallel zum ursprünglichen Win11 mit der standardmäßigen 100 MiB ESP.

 

[Caramon2]

Moin.

Ich habe oben zum Vergleich noch die Bootloader von LMDE 7 und Artix hinzugefügt.

Meine Empfehlung:

Wenn man Windows (z. B. neues Laufwerk, neuer PC) sowieso frisch installieren will, erstellt man am besten vorher (z. B. von einem Linux-Livesystem aus) die ESP mit 1007 MiB: Zusammen mit dem 1 MiB am Anfang und der leeren 16 MiB "Windows Reserved"-Partition, die er Windows-Installer dann bei der Installation erstellt, ergibt das ein glattes GiB *), bei dem die Windows-Partition dann beginnen wird: Das kann man sich gut merken und selbst für Solus hat man dann mehr als genug Luft (z. B. um mehrere Soli zu vergleichen: Budgie, KDE, usw.).

Mit GParted (ich nutze dafür das deutsche LMDE 7) erstellt man die ESP so:

Zuerst die GPT-Partitionstabelle erstellen:

Auf dem "nicht zugeteilten" Bereich Rechtsklick/Neu:

(fat16, damit man eine vernünftige Clustergröße bekommt *) )​

Dann im Hauptfenster oben auf Anwenden und anschließend die Partition als "esp" markieren ("boot" wird automatisch gesetzt):

Und fertig:

Jetzt kann Windows in dem freien Bereich installiert werden.

Als angenehmer Nebeneffekt erstellt der Installer dann übrigens keine extra Recovery-Partition *) (das kommt mit auf C: ), so dass MS es nicht wieder wie vor einigen Jahren zerschießen kann, weil die Recovery-Partition zu klein für das Update war.

---

*)
Keine extra Recovery-Partition:

Ein glattes GiB:

Die Installation habe ich jetzt als Referenz-Windows übernommen: Das ist zwar nicht mehr standardmäßig, aber ich kann dann wenigstens Installationen mit zu großen Bootloadern abschließen und dann nachsehen wie viel Platz der braucht.

Zur Clustergröße:

Die standardmäßige 100 MiB ESP wird mit fat32 formatiert und hat deshalb eine Clustergröße von nur 1k! - Das ist bei Laufwerken mit 4k Sektoren (also alle SSDs und moderneren HDDs) vergleichbar mit einem falschen Alignment:

Interessant aber, dass sogar Windows 11 noch Teile von MS-DOS 5.0 enthält.

 

[Caramon2]

Update:

Nachdem ich Solus neben der neuen Windows 11 Installation mit der 1 GiB ESP (s. u.) installiert habe, wurde der Bootloader zwar installiert, aber beim Reboot bootete Solus direkt: Es gab kein Boot-Menü mit Windows!

Ich kontrolliere "/etc/default/grub": 5 Sek. Timeout und der os-prober war auch nicht deaktiviert, also sudo update-grub: Fehlermeldung: "/boot/grub/grub.cfg.new" würde nicht existieren.

1. ist das sowieso der falsche Name, 2. existierte das ganze Verzeichnis "/boot/grub/" nicht und 3., wurde die ESP gar nicht erst in /boot/grub/efi/ eingehängt!

WAS FÜR EIN SCHROTT !!!!!!!!!

Ich habe die Schnauze voll: Solus wird platt gemacht, das ISO gelöscht und ich rühre diesen Mist nie wieder an. Punkt!

Zum Vergleich das gleiche nach einer LMDE 7-Installation:

Das Bootmenü ist mit Windows:

Und die ESP war auch korrent eingehängt:

Die extra Home-Partition hat damit nichts zu tun. Ich wollte bei der Gelegenheit noch was anderes ausprobieren.

 

[Caramon2]

Moin!

Solus hatte sich übrigens trotzdem für mich gelohnt:

Ich habe schon seit 2010 aus finanziellen Gründen kein Festnetz mehr und über Mobilfunk nur begrenzten Traffic. Inzwischen aber 17 GiB/Mon. (für 8€ bei Sim.de) und Ende l. Monats noch 7 GiB Rest, den ich nicht verfallen lassen wollte. Da kam am 29. die Meldung der neuen Solus-Version gerade recht: Das hatte ich mir seit dem beinahe-aus nicht mehr angesehen und da Xfce mit dieser Version den Beta-Status verließe, passte um so besser: Xfce gab zu der Zeit, als ich mich mehr mit Solus beschäftigt habe, noch nicht und es hieß von den Machern ausdrücklich: Xfce wird für Solus niemals kommen…

Trotz des anschließenden "Desasters" habe ich dadurch wenigstens bemerkt, dass die LinuxMint Debian-Edition gar nicht mehr den rel. schlechten Treiber wie damals generell von CUPS für meinen Drucker genutzt wurde (LinuxMint, Manjaro, …) nutzt - weshalb ich mir den "brother-hl2030" aus dem AUR installiert hatte, bei dem es eine Warnung gab, dass das nicht mehr lange von CUPS unterstützt werden wird und der auch eine 32-bit-Abhängigkeit hatte (das einzige lib32 in meinem System):

Paket (2)           Neue Version              Netto-Veränderung
lib32-glibc         2.42+r33+gde1fe81f4714-1          18,48 MiB 
brother-hl2030      2.0.1-6                            0,12 MiB

Stattdessen nutzte schon LMDE 6 einen "brlaser" (ohne Solus wäre ich vermutlich nie auf die Idee gekommen bei LMDE den Druckertreiber zu kontrollieren), bei dem weder eine Warnung kommt, noch brauchte er 32-bit:

Paket (1)            Neue Version  Netto-Veränderung
brlaser  6.2.8-1                           0,07 MiB

Dazu gefällt mir der "Milky-Way"-Hintergrund sehr gut, besonders in Verbindung mit Vertex-Dark, weshalb ich ihn für mein Produktivsystem übernommen habe:

Da ich neulich außerdem festgestellt habe, dass bei Wine wow64 inzwischen Standard ist *), also auch keine 32-bit-Abhängigkeiten mehr hat, habe ich 64 und 64 zusammengezählt, es wieder in mein (jetzt vollständig "reines" 64-bit) Produktivsystem installiert und die "Artix+Wine"-Installation, die ich nur erstellt hatte, um die 32-bit-libs dorthin auszulagern, gelöscht (inkl. aller Sicherungen). - Meine ext. SSD habe ich dabei etwas umstrukturiert:

alt (noch mit Solus):

neu (oben hatte ich nicht daran gedacht, die HomeC für den Screenshot zu entsperren):

Die Artix-eSSD-Partition habe ich direkt vor die verschlüsselte Home-Partition gesetzt, da beides zusammen gehört: Die bootfähige 1:1 Kopie meines Produktivsystems. = Ein voll ausgestattetes Notsystem, das ich überall booten kann um zu helfen und nebenbei eine zusätzliche Sicherung. - Deshalb ist beides auf einer primären Partition, bei Windows hat man ja sowieso keine andere Wahl und der erweiterte Partition bleibt für den unwichtigen Kram, wie z. B. weitere Testinstallationen, oder zu temporären Zwecken.

Und ohne Solus hätte ich auch keine neue Windows 11 Referenz-Installation: Mit 1 GiB ESP mit vernünftiger Clustergröße und ohne extra Recovery-Partition, womit zwei potenzielle Stolpersteine aus dem Weg sind: Wie in #17 gezeigt.

---

*) ich nutze normalerweise nur die .0er Versionen, da das die Stable sind: Alle folgenden sind sozusagen Betas für die nächste .0er Version, was man momenten bei der Git-Version gut sieht:

Installiert ist die 10.20:

$ pacman -Qs wine-git
local/wine-git 10.20.r236.g9daccb7-1
    A compatibility layer for running Windows programs

Tatsächlich meldet sie sich aber als die 11.0-rc1:

Übrigens gibt es keine speziellen wow64-Versionen mehr, da das inzwischen in der normalen Version integriert ist:

Transition to the new WoW64 wine and wine-staging

We are transitioning the wine and wine-staging package to a pure wow64 build. This change removes the dependency on the multilib repository for wine and wine-staging.

The main reason for this is to align with upstream Wine development, which simplifies packaging and the dependency chain.

Hier das Arch-Wiki dazu: 32-bit Windows Applications

Alles weitere dazu dann dort im Thread.