Also ich würde jetzt in den sauren Apfel beissen und das System neu aufsetzen... Denn auch wenn man jetzt noch eine Lösung finden würde, wäre mir die Gefahr zu groß, dass irgendeine Inkonsistenz später wieder für Probleme sorgt.
Beiträge von Spaceloop
-
-
Wenn das Bootmedium eine UEFI-Umgebung erkennt, sollte es laut
Boot parameters | openSUSE Leap 15.5openSUSE Leap allows setting several parameters during boot, for example choosing the source of the installation data or setting the network configuration.doc.opensuse.orgin GRUB die Möglichkeit geben, unter More-> eine Recovery-Umgebung zu starten. Klappt das?
Ansonsten: Startet z.B. eine aktuelle Tumbleweed-Live-CD mit XFCE auf den Desktop?
openSUSE TumbleweedLearn about the openSUSE distributions and download them for freeget.opensuse.orghttps://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-XFCE-Live-x86_64-Current.iso
was liefert
-
In den vergangenen Wochen wurde an verschiedenen Macros im OBS gedreht, sodass nun zum ersten mal bitidentisch reproduzierbare Pakete in den Tumbleweed-Repos landen. Das bedeutet, dass bei gleichem Sourcecode, gleicher Bauumgebung und gleichen Bauanleitungen nun sicher auch immer die gleichen Pakete im Ergebnis dabei rauskommen.
Unter anderem wird eine Korrumpierung des ganzen Prozesses dadurch erschwert bzw. fällt leichter auf. Insgesamt bedeutet dies einen noch definierteren Buildprozess und einen Sicherheitsgewinn für die Nutzer.
vgl.
openSUSE Factory enabled bit-by-bit reproducible buildsIn March, the configuration for building openSUSE Factory was changed to be bit-by-bit reproducible (except for the embedded signature). Following this, the ...news.opensuse.orgHistory — reproducible-builds.org
Soweit ich weiß, können das bisher nur ganz wenige Distributionen (NixOS?).
-
Das hängt von der verwendeten Hardware ab. Ich hatte vor einiger Zeit Tumbleweed mal auf einem China-Tablet installiert, es war über Touch bedienbar.
Es gibt auch unterschiedliche Grade der Nutzbaren Funktionalität. Bei manche Hardware geht nur Einfach-Touch und keine Multitouch-Gesten. Oder ein Zusatzstift für Notizen lässt sich gar nicht oder nur eingeschränkt nutzen. Hängt wie gesagt vom Einzelfall ab.
Dann ist Touch in den verschiedenen Desktops unterschiedlich gut nutzbar implementiert. Einige Einfach-Desktops können gar nichts damit anfangen.
Die meiner Meinung nach konsistenteste Touch-Bedienung hat Gnome.
-
Habs jetzt geschafft.
Habe mich an die Anleitung aus dem englischen Forum von 2014 gehalten. Allerdings habe ich in der Zeile in der rules-Datei grundsätzlich "Shift+2 Anführungszeichen" benutzt.
/etc/udev/rules.d/68-vhba.rules
Code# Datei für CDEMu Daemon # KERNEL=="vhba_ctl", NAME="%k", MODE="0666", OWNER="root", GROUP="users"
/etc/modules-load.d/vhba.conf
Warum das jetzt so geklappt hat, und vorher nicht, weiss ich nicht.
Es empfiehlt sich, gcdemu als GUI dazu zu installieren. Es stammt aus der GNOME-Ecke und nutzt GTK, läuft aber auch unter KDE.
Damit kann man einfach per Maus ein paar CD-Hardware-Tweaks einstellen wie Bad Sector Emulation, Übertragungsratenemulation usw. Sobald das Image mit gcdemu geladen wird, poppt in KDE der gewohnte Hinweis "Datenträger und Geräte" - Optische Disk - einhängen usw. auf, d.h. KDE denkt, es handelt sich um eine echte CD/DVD.
So wollte ich das haben.
-
Ich wollte eigentlich kein Extra-Repo einbinden. Ich müsste die Prio des KDE-Repos runtersetzen, damit nicht alle KDE-Anwendungen über das KDE Repo aktualisiert werden? Wird dieses Repo über OBS erzeugt?
Zudem scheint acetoneiso2 nach dem was Wikipedia schreibt, ja eher ein Iso-Viewer zu sein? Wenn es nur um das Anzeigen geht, komme ich aktuell auch schon in Dolphin über Aktionen --> ISO anzeigen "in" das ISO.
(Leider funktioniert ein schneller Test mit
nicht, vermutlich da es über Fuse läuft?)
CDEmu scheint tiefer im System anzusetzen und das "glaubhaftere" virtuelle CD-Laufwerk bereitzustellen. Es kann wohl auch mit einigen einfachen "Lesefehlern" auf dem Medium umgehen.
-
Hallo,
ich wollte mal einige meiner alten DOS- und Windows 98-Spiele unter Playonlinunx oder WINE testen. Dazu habe ich unter Leap (noch 15.4) die CDEmu-Pakete installiert.
Leider lässt sich CDEMu nicht starten.
ZitatFEHLER: Fehler beim Verbunden zum CDEmu Daemon: g-io-error-quark: Error calling StartServiceByName for net.sf.cdemu.CDEmuDaemon: Timeout was reached (24)
nach etwas Recherche habe ich dann den CDEmu-Daemon direkt aufgerufen.
Code
Alles anzeigengk@linux:~> cdemu-daemon Starting CDEmu daemon with following parameters: - config file: (null) (exists: 0) - num devices: 1 - control device: /dev/vhba_ctl - audio driver: null - bus type: session - default CDEmu debug mask: 0x0 - default libMirage debug mask: 0x0 cdemu0: Kernel I/O: failed to open control device /dev/vhba_ctl: Keine Berechtigung! cdemu: Daemon: failed to start device #0! cdemu: Daemon: failed to create device! Daemon initialization and start failed!
Nach weiterer Recherche bin ich auf einem Beitrag der Gentoo-Kollegen in deren Bugtracker gestoßen:
CodeThe udev rules needs to be changed to the following: KERNEL=="vhba_ctl", SUBSYSTEM=="misc", TAG+="uaccess", TAG+="udev-acl" TAG+="uaccess" is for logind while TAG+="udev-acl" is for ConsoleKit. Tested and working for me.
CodeNon logind/ConsoleKit systems can create /etc/udev/rules.d/69-vhba.rules with the following: KERNEL=="vhba_ctl", SUBSYSTEM=="misc", MODE="0660", GROUP="cdrom" and add their user to the cdrom group.
Ich verstehe das so, dass man unter /etc/udev/rules.d eine Textdatei 69-vhba.rules anlegen muss.
Kann man in der Datei dann die Zeile KERNEL=="vhba_ctl", SUBSYSTEM=="misc", MODE="0660", GROUP="cdrom" als Einzeiler übernehmen, oder muss das untereinander?
Verwendet openSUSE logind/consolekit oder nicht? Welche der beiden Varianten sollte man versuchen bzw. gibt es noch andere openSUSE-Besonderheiten, die zu beachten sind?
-
Auch bei einem Leap Upgrade werden die Fonts erhalten.
Na prima. Unabhängig davon verstehe ich das Problem ohnehin nicht. Wenn man die eigenen Fonts übertragen will, dann kopiert man das Verzeichnis vorher auf einen USB-Stick, eine CD/DVD oder einfach in ein entsprechend angelegtes Unterverzeichnis im Home-Verzeichnis und kopiert das nach dem Update wieder zurück.
Also was jetzt?
Meine Frage rührt daher, dass ich in verschiedenen Quellen gelesen hatte, wie einfach es sei, im Linux-Desktop die Einstellungen von einer Installation auf die andere zu übertragen: einfach alle Konfigurationsdateien (in der Regel versteckt mit .punkt) im Home-Verzeichnis rüberkopieren. Bei der Schrifteninstallation ist mir aber nun aufgefallen, dass diese nicht unter Home installiert werden, sondern irgendwo im System. Und gerade bei einem Upgrade würde ich es nicht ausschließen wollen, dass dabei auch einmal größere Umbauten durchgeführt werden und sich Pfade ggf. ändern können.
Genau wie bei den Hintergrundbildern in /usr/share/wallpapers sollte man also auch bei den Fonts etwas aufpasssen...
-
Hallo,
kurze Frage:
Wenn man von einer alten Schriftarten-CD Truetype-Fonts nach /usr/share/fonts/truetype kopiert hat: kann man davon ausgehen, dass diese nach einem Distributionsupgrade noch da sind? (Leap und Tumbleweed)
-
Eine Immutable-Distribution kann durchaus ganz nett sein. Das Kernsystem kann sich angeblich im laufenden Betrieb updaten. Die Flatpaks stößt Discover oder GNOME Software an, sodass sich das ganze ähnlich wie beim Handy anfühlt.
Allerdings hätte ich Yast schon ganz gern dabei!