Systemumzug auf neue Hardware
Hallo, ich will mein opensuse leap 15 von einen (sehr) alten Rechner ohne UEFI auf einen neuen mit UEFI-Bios umziehe. Im alten Rechner sind / und /home auf getrennten Partitionen /etc/fstab UUID=498b4168-3b86-4375-8d73-69ce91714f5f swap swap defaults 0 0 UUID=b55a273e-deac-4264-ac1a-9c37843f6678 swap swap defaults 0 0 UUID=59259677-fb46-4b39-a7cd-72a2e0687277 / ext4 acl,user_xattr 1 1 UUID=6dc1df34-cca3-47dd-9be3-4626afcb5a94 /home xfs defaults 1 2 /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246JDWSA65315-part1 /backup ext3 acl,user_xattr 1 1 /dev/disk/by-id/ata-ST3500413AS_Z2A8HWPT-part1 /backup2 ext4 acl,user_xattr 1 2 Auf dem Neuen würde es dann so aussehen: # /etc/fstab: static file system information. # # <file sys> <mount point> <type> <options> <dump> <pass> # device during installation: /dev/nvme0n1p2 UUID=0dd9315b-f57a-41b2-ad39-520ec4274158 / ext4 defaults 0 1 # device during installation: /dev/nvme0n1p1 UUID=483B-7EA5 /boot/efi vfat rw 0 2 # device during installation: /dev/nvme1n1p1 UUID=b3a4c1d0-0710-4edc-bea3-dc84f8ed241f /home ext4 defaults 0 2 # device during installation: /dev/sda1 UUID=7ee633cb-2961-4473-8a88-2484e8780601 /datadisk2 ext4 noauto,user 0 2 # device during installation: /dev/nvme0n1p3 UUID=fbb099fa-8cfe-40ac-afbe-2fcb37b6bbe3 none swap sw 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 ro,user,noauto 0 0 Die beiden /backup und /backup2 wandern in die HDD: UUID=7ee633cb-2961-4473-8a88-2484e8780601 das root inkl. boot nach der SSD: UUID=59259677-fb46-4b39-a7cd-72a2e0687277 und /home in die SSD: UUID=6dc1df34-cca3-47dd-9be3-4626afcb5a94 Übersetzt lauten die UUIDs dann: ll /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 15 Apr 5 16:04 0dd9315b-f57a-41b2-ad39-520ec4274158 -> ../../nvme1n1p2 lrwxrwxrwx 1 root root 15 Apr 5 16:04 483B-7EA5 -> ../../nvme1n1p1 lrwxrwxrwx 1 root root 10 Apr 5 16:04 7ee633cb-2961-4473-8a88-2484e8780601 -> ../../sda1 lrwxrwxrwx 1 root root 10 Apr 5 15:59 9C41-74D5 -> ../../sdf1 lrwxrwxrwx 1 root root 15 Apr 5 16:04 b3a4c1d0-0710-4edc-bea3-dc84f8ed241f -> ../../nvme0n1p1 lrwxrwxrwx 1 root root 15 Apr 5 16:04 fbb099fa-8cfe-40ac-afbe-2fcb37b6bbe3 -> ../../nvme1n1p3 Umziehen wollte ich per rsync, erst auf externe Platte, dann von dieser auf den neuen Reczhner mit dem Befehl rsync --stats --progress --numeric-ids -axAhHSP /mnt/alt/ /mnt/neu Danach sollte ich wohl auf der Kopie in der Datei /boot/grub2/grub.cfg die UUIDs tauschen, wohl am Besten mit suchen & ersetzen. also (/ alt) 59259677-fb46-4b39-a7cd-72a2e0687277 -> (/ neu) 0dd9315b-f57a-41b2-ad39-520ec4274158 Ist das korrekt so? Muss ich noch einen Datei anpassen? Worin ich mich gar nicht auskenne ist die Sache mit dem UEFI. Wenn ich bisher ein System umgezogen habe, habe ich zuerst von einer DVD oder Stick gebootet, dann mount /dev/nvme1n1p2 /mnt mount --bind /dev /mnt/dev mount --bind /sys /mn/sys mount --bind /proc /mnt/proc chroot /mnt und jetzt kommt die Frage, wohin zeigt grub2-install? In die EFI Partition /dev/nvme1n1p1, also grub2-install /dev/nvme1n1p1? grub2-mkconfig -o /boot/grub2/grub.cfg Da in dem Neuen Rechner eine neuere, leistungsstärkere Nvidia-Karte steckt, muss ich diese # zypper se -si nvidia Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+-------------------------------+---------+--------------------------------------+--------+------------------------ i+ | nvidia-computeG03 | package | 340.107-lp150.12.2 | x86_64 | nVidia Graphics Drivers i+ | nvidia-gfxG03-kmp-default | package | 340.107_k4.12.14_lp150.11-lp150.12.2 | x86_64 | nVidia Graphics Drivers i+ | nvidia-glG03 | package | 340.107-lp150.12.2 | x86_64 | nVidia Graphics Drivers i+ | nvidia-uvm-gfxG03-kmp-default | package | 340.107_k4.12.14_lp150.11-lp150.12.1 | x86_64 | nVidia Graphics Drivers i+ | x11-video-nvidiaG03 | package | 340.107-lp150.12.2 | x86_64 | nVidia Graphics Drivers durch diese # zypper se -si nvidia Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+---------------------------+---------+------------------------------------+--------+------------------------------- i+ | nvidia-computeG05 | package | 418.43-lp150.9.1 | x86_64 | TUXEDO Computers - 15.0 NVIDIA i+ | nvidia-gfxG05-kmp-default | package | 418.43_k4.12.14_lp150.11-lp150.9.1 | x86_64 | TUXEDO Computers - 15.0 NVIDIA i+ | nvidia-glG05 | package | 418.43-lp150.9.1 | x86_64 | TUXEDO Computers - 15.0 NVIDIA i+ | x11-video-nvidiaG05 | package | 418.43-lp150.9.1 | x86_64 | TUXEDO Computers - 15.0 NVIDIA ersetzen. Mache ich wohl am Besten mit einem Yast in der Konsole, falls X nicht läuft, oder gibt es da auch einen zypper Befehl? Frage ist dann noch, ob die neue Netzwerkkarte mit der alten Konfiguration läuft, oder ob ich da auf der Kopie auch noch eine datei editieren muss, vor dem Kopieren auf das Zielsystem? Also viele Frage, vielleicht bekomme ich zielführende Antworten. Danke. Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Freitag, den 05.04.2019, 18:04 +0200 schrieb Herbert Albert:
Hallo,
ich will mein opensuse leap 15 von einen (sehr) alten Rechner ohne UEFI auf einen neuen mit UEFI-Bios umziehe.
Hallo, in so einem Fall würde ich das OS _immer_ neu installieren. -- Klaus Bernhard Klose -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Samstag, 6. April 2019, 12:01:36 CEST schrieb Klaus Klose:
Am Freitag, den 05.04.2019, 18:04 +0200 schrieb Herbert Albert:
Hallo,
ich will mein opensuse leap 15 von einen (sehr) alten Rechner ohne UEFI auf einen neuen mit UEFI-Bios umziehe.
Hallo,
in so einem Fall würde ich das OS _immer_ neu installieren.
-- Klaus Bernhard Klose ist Antwort begrüntet? Ich habe viele spezielle Anwendungen installiert und es macht viel Arbeit sich da alles wieder zusammen zu suchen. Was spricht gegen meine Vorschlag? Vor Jahren (da waren die SuSE Nummern meist noch einstellig) habe ich das auch so bzw. so ähnlich (Lilo anstatt grub) gemacht.
Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Samstag, den 06.04.2019, 15:48 +0200 schrieb Herbert Albert: Hallo Herbert
ist Antwort begrüntet?
Pragmatisch. Wenn ich mir neue Hardware zulege, die ich dann auch über Jahre nutzen will, dann ist eine an diese Hardware exakt angepasste Installation für mich alternativlos. Dafür nehme ich den Aufwand, eine solche Installation zu planen, zu organisieren, und letztendlich durchzuführen in Kauf. Rechne da von vorne herein schon damit, dass so etwas nicht nur 5 Minute oder 5 Stunden braucht. 5 Tage oder sogar 1 Woche ist da für mich ein durchaus realistischer Zeitrahmen.
Ich habe viele spezielle Anwendungen installiert und es macht viel Arbeit sich da alles wieder zusammen zu suchen. Das zusammen suchen scheint ein echtes Problem mit opennSUSE zu sein? Denn mit meiner Distribution bekomme ich alles was ich benötige aus einer Hand und mit wenigen Handgriffen installiert.
Was spricht gegen meine Vorschlag? Vor Jahren (da waren die SuSE Nummern meist noch einstellig) habe ich das auch so bzw. so ähnlich (Lilo anstatt grub) gemacht. Siehe oben. Ich kann mir eine alte Installation natürlich passend machen. Und habe in der Folge meist endlose kleine, oder auch große Probleme damit. Das konnte ich bisher immer gut vermeiden.
Und nicht zuletzt, geht bei der Neuinstallation und Konfiguration irgend etwas schief, dann habe ich immer noch den Rechner mit der alten Installation. So etwas geht bei mir erst dann außer Betrieb, wenn ich mir zu 100 Pro sicher bin, dass die neue Einrichtung zuverlässig arbeitet. Was meistens noch mal 1-2 Wochen Zeit in Anspruch nimmt. -- Klaus Bernhard Klose -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 06.04.2019 um 18:07 schrieb Klaus Klose:
Am Samstag, den 06.04.2019, 15:48 +0200 schrieb Herbert Albert:
Hallo Herbert
ist Antwort begrüntet?
Pragmatisch. Wenn ich mir neue Hardware zulege, die ich dann auch über Jahre nutzen will, dann ist eine an diese Hardware exakt angepasste Installation für mich alternativlos. Dafür nehme ich den Aufwand, eine solche Installation zu planen, zu organisieren, und letztendlich durchzuführen in Kauf. Rechne da von vorne herein schon damit, dass so etwas nicht nur 5 Minute oder 5 Stunden braucht. 5 Tage oder sogar 1 Woche ist da für mich ein durchaus realistischer Zeitrahmen.
Ich habe viele spezielle Anwendungen installiert und es macht viel Arbeit sich da alles wieder zusammen zu suchen. Das zusammen suchen scheint ein echtes Problem mit opennSUSE zu sein? Denn mit meiner Distribution bekomme ich alles was ich benötige aus einer Hand und mit wenigen Handgriffen installiert.
Das Installieren ist meiner Erfahrung nach nicht das Problem. Was der eigentliche Aufwand ist, ist das Konfigurieren. Aus diesem Grunde halte ich das simple Neuinstallieren eines Systems als Ersatz für ein jahrelang benutztes System für völligen Schwachsinn, so etwas würde mir jedenfalls nie in den Sinn kommen. Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Sat, 6 Apr 2019 19:12, Manfred Kreisl wrote:
Am 06.04.2019 um 18:07 schrieb Klaus Klose:
Am Samstag, den 06.04.2019, 15:48 +0200 schrieb Herbert Albert:
Hallo Herbert
ist Antwort begrüntet?
Pragmatisch. Wenn ich mir neue Hardware zulege, die ich dann auch über Jahre nutzen will, dann ist eine an diese Hardware exakt angepasste Installation für mich alternativlos. Dafür nehme ich den Aufwand, eine solche Installation zu planen, zu organisieren, und letztendlich durchzuführen in Kauf. Rechne da von vorne herein schon damit, dass so etwas nicht nur 5 Minute oder 5 Stunden braucht. 5 Tage oder sogar 1 Woche ist da für mich ein durchaus realistischer Zeitrahmen.
Ich habe viele spezielle Anwendungen installiert und es macht viel Arbeit sich da alles wieder zusammen zu suchen. Das zusammen suchen scheint ein echtes Problem mit opennSUSE zu sein? Denn mit meiner Distribution bekomme ich alles was ich benötige aus einer Hand und mit wenigen Handgriffen installiert.
Das Installieren ist meiner Erfahrung nach nicht das Problem. Was der eigentliche Aufwand ist, ist das Konfigurieren. Aus diesem Grunde halte ich das simple Neuinstallieren eines Systems als Ersatz für ein jahrelang benutztes System für völligen Schwachsinn, so etwas würde mir jedenfalls nie in den Sinn kommen.
Manfred
Nonalerweise würde ich mich in so eine Debatte nicht einmischen. ABER: 25 Jahre als Admin sagen mir einiges mehr als "Tante Google" oder "Onkel Forum". 1. Jedes lange genutzte System sammelt (Daten-)Müll an. 2. Ein System das nicht von einer Dokumentieren Anleitung neu aufgesetzt (installiert und konfiguriert) werden kann ist sehr wahrscheinlich das nächste das mit Hard- und oder Soft- ware Defekten sich verabschiedet. 3. Ein "Umzug" eines mehr als zwei, maximal drei Jahre alten Systems (seit dem letzten neu Aufsetzen) kann nur als kurzfristige (IMHO 3 Monate) Zwischenlösung gelten, siehe 1. 4. Ein signifikanter Wechsel in der Hardware (mehr als eine Prozessor und, oder GPU Generation, oder Wechsel von BIOS zu UEFI) ohne komplete Neuinstallation und Konfiguration wärend das "alte" System noch läuft, ist eine direkte Einladung an Murphy mal vorbei zu schauen. 5. Mach's doch, resevier aber bitte rechtzeitig Artzttermine für Magengeschüre und Migräne. Es steht allen natürlich frei derartige Hinweise zu ignorieren, aber dann müßt Ihr auch Schadenfreude von anderen hinnehmen. Mein Tip wäre das System auf der Neuen Hardware Neu aufsetzen und dann Stück für Stück die Konfiguration auf dem Neuen System von Grund auf zu Machen. Gleich zeitig das Ganze dokumentieren. Spart im Ernstfall Zeit, Nerven, Schweiss, Blut und Tränen. Das war mein Wort zum Sonntag dazu. - Yamaban.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Samstag, den 06.04.2019, 15:48 +0200 schrieb Herbert Albert:
ist Antwort begrüntet? Ich habe viele spezielle Anwendungen installiert und es macht viel Arbeit sich da alles wieder zusammen zu suchen.
Spezielle Anwendungen für was? Spontan fallen mir zwei Vorgehensweisen ein: 1) Downloadseite(n) im Browser bookmarken und die Bookmarks dann exportieren. Nach der Neuinstallation können diese dann wieder importiert werden und man findet ruck zuck seine Programme. 2) Heruntergeladene Programme / Pakete auf einen externen Datenträger wegsichern, damit diese nach der Neuinstallation wieder eingespielt werden können.
Was spricht gegen meine Vorschlag? Vor Jahren (da waren die SuSE Nummern meist noch einstellig) habe ich das auch so bzw. so ähnlich (Lilo anstatt grub) gemacht.
Vom Prinzip her kannst Du das so machen, sofern Du hierbei 2 Dinge beachtest: 1. aktiviere in Deinem neuen System in der UEFI-Firmware das Compatibility Support Module (CSM) und 2. verwende das MBR-Partitionierungsschema. Dann solltest Du die wenigsten Probleme haben. Alternativ kannst Du natürlich unter einem 64-bit Linux auch das neue und zeitgemäßere GPT-Schema nutzen - trotz aktivem CSM. Dieses Vorgehen macht die Partitionierung jedoch ein klein wenig komplizierter. - -- MfG Richi -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEL3uOiU4ourJELXQ54DdiOpwB5zsFAlyo+1MACgkQ4DdiOpwB 5zvayxAAxGVHm4X0QLqd5ZHAkkwKeeGDaePNhJdu7z26fZNcJRph3QMxenb78861 8Y6WuoRULDfJBRTERkZxUKQWOcLKda/KP9o3Ys3cLwgNxZLlqazSLvoZWYnYtg1Z 6H24UeIZI0keKrGxjjZHsiHgoN3VqiZiEHu31w180ludrFjTMOHXHiCytwmyfwVf wsTKYdRlfRVwcyobW3/4j2oeZEQM+48JdOIYUoNqqC5vFtcRwaz0AvCOcxtO5EXC GIgtfSqypTznRyw0UTdA73ZvZwpLKFADjSAzbGWbDK55D93qgaqwG/FN+F6sWAGa n4aiMDSb7e38yIUQLzAdzsl81J5CCCfQvNwhGRFWd3VbNt7oubbjX9JrPwwfkFyO biWq4CGuLPiykm5qYvMxh6PXy7c2+O36TSfRITBkUB7hU3JNdxXmii+hVz3+Kzr8 JlHxuhaVcbTCnHO925241zyEdWWKKYw7/J7EqBrSNguO4NQICNkgqFha6yFjaDle j2CxGWqzU7oNPWCEHM+2djLeX2DRbwIA8Mg+GNoQ3+pPUUzOWg9Jwgk5/CbuiE5e TBGJsBu+YkSlbUrJTFgRCVVSf3uUqg8s3VxnKY2XXoSjZJtOSlKWUTAj51pJDnBo xd+EO0Zxt/fJ2wlx2tAVxw108piV4nGzLEwQiTqfJiAZqdBBRKY= =vCMD -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Samstag, 6. April 2019, 21:17:44 CEST schrieb Richard Kraut:
Am Samstag, den 06.04.2019, 15:48 +0200 schrieb Herbert Albert:
ist Antwort begrüntet? Ich habe viele spezielle Anwendungen installiert und es macht viel Arbeit sich da alles wieder zusammen zu suchen.
Spezielle Anwendungen für was?
Spontan fallen mir zwei Vorgehensweisen ein:
1) Downloadseite(n) im Browser bookmarken und die Bookmarks dann exportieren. Nach der Neuinstallation können diese dann wieder importiert werden und man findet ruck zuck seine Programme.
2) Heruntergeladene Programme / Pakete auf einen externen Datenträger wegsichern, damit diese nach der Neuinstallation wieder eingespielt werden können.
Was spricht gegen meine Vorschlag? Vor Jahren (da waren die SuSE Nummern meist noch einstellig) habe ich das auch so bzw. so ähnlich (Lilo anstatt grub) gemacht.
Vom Prinzip her kannst Du das so machen, sofern Du hierbei 2 Dinge beachtest:
1. aktiviere in Deinem neuen System in der UEFI-Firmware das Compatibility Support Module (CSM) und
2. verwende das MBR-Partitionierungsschema. Dann solltest Du die wenigsten Probleme haben.
Alternativ kannst Du natürlich unter einem 64-bit Linux auch das neue und zeitgemäßere GPT-Schema nutzen - trotz aktivem CSM. Dieses Vorgehen macht die Partitionierung jedoch ein klein wenig komplizierter.
--
MfG Richi Hallo Richard
Zum Ersten: Vielleicht verstehen wir uns da falsch. Es ist ein neuer Rechner, d.h., /home zieht komplett mit um. den Punkt 2. habe ich in meiner Antwort an Jan beschrieben (wenn Du das so meinst). Zum Zweiten: Das System ist schon Partitioniert (siehe meine Anfangs-Mail). Es geht mir ja nur darum, wohin grub installiert wird. Warum CSM aktivieren, wird davon nicht abgeraten? Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Samstag, den 06.04.2019, 22:18 +0200 schrieb Herbert Albert:
Zum Ersten: Vielleicht verstehen wir uns da falsch. Es ist ein neuer Rechner, d.h., /home zieht komplett mit um. den Punkt 2. habe ich in meiner Antwort an Jan beschrieben (wenn Du das so meinst).
Die Variante, welche Du da beschreiben hast, wäre die eleganteste. Ich hatte Deine erste Mail so verstanden, dass Du Dein aktuell laufendes System via rsync auf das neue umziehen möchtest. Also nicht nur /home, sondern wirklich das "ganze" System.
Zum Zweiten: Das System ist schon Partitioniert (siehe meine Anfangs-Mail).
Genau das habe ich komplett übersehen. Dann ist auch die Sache mit dem CSM hinfällig.
Es geht mir ja nur darum, wohin grub installiert wird.
Nach wie vor in den Bootsektor der ersten SSD, von der gebootet werden soll. Also quasi die Entsprechung von bspw. /dev/sda bei klassischen SATA- Festplatten/SSDs.
Warum CSM aktivieren, wird davon nicht abgeraten?
Wenn Dein System, wie Du erwähnt hast, bereits im UEFI-Modus installiert wurde, würde ich es jebenfalls _nicht_ aktivieren. Ach ja. Secure Boot sollte auch abgeschaltet sein/werden. openSUSE unterstützt dieses Feature zwar, aber es kommt in Verbindung hiermit immer wieder zu Problemen. Und die kommerziellen nVidia-Kerneltreibermodule funktionieren damit auch nicht. - -- MfG Richi -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEL3uOiU4ourJELXQ54DdiOpwB5zsFAlypDxYACgkQ4DdiOpwB 5zscGBAAgF23BO7AFA6on1h9GChwOVzMRL9zG9A04f2f1H1I+HWrjgfMoy2icNk2 w6qzpLPpvtn32aDJokLaLlr2RdJu7qcRmggmC/FEPKD1WCNx726mRAElwAcxIas2 syKXPp8Z3qrJ75+s+3P/SNn08o+o5EY/ewk+O4KrzXE6pRDH+A1I7PAGhC197LON ADXiJCl2vujh0OLX2C/E5m+xUfAOYQIMLS+HGgpwqHhy9zJrTQbw1oGz7ntTWBkE pJdVtzZNrvDNaI9tNwF9vuBKqX5EgrglqhVOZt5QZb3NtSc4oC/egGoSE0noGdBq acuyrPclHzpvpjFMZDT7vcgyJj8dAR29ske1rOXTz94yc8vJoxAdBpfWDdEYnqW/ 7q16RGWn9xKNb7+JnL2UppxbUvXD40vM1sNxC1/Ts6vGOUa9pMAedw6ERK3Yfodl L0vr5zwuvUcvo6pjYkWVnMd4oOd7DiK7bX1xm0QADGwITfdWtL1GfczqbXRXyJIH YA19t0yXZGlzgKmQ45AlsJbbO0tXR5W1G0FivSZT09ztkroMtgLug/2mfUhmNCVV 34ZgaB7ikv2776LwB9eS24X4edcn7GFBRRb6ql1V/yF20gBdMzSJ3GWZ1L7kBk4c F82aXHU3LDeFs71+9dl+XtZP6cnldVtohKYcIdp/NFIlBNmTiCg= =dziL -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Samstag, 6. April 2019, 22:42:02 CEST schrieb Richard Kraut:
Am Samstag, den 06.04.2019, 22:18 +0200 schrieb Herbert Albert:
Zum Ersten: Vielleicht verstehen wir uns da falsch. Es ist ein neuer Rechner, d.h., /home zieht komplett mit um. den Punkt 2. habe ich in meiner Antwort an Jan beschrieben (wenn Du das so meinst).
Die Variante, welche Du da beschreiben hast, wäre die eleganteste. Ich hatte Deine erste Mail so verstanden, dass Du Dein aktuell laufendes System via rsync auf das neue umziehen möchtest. Also nicht nur /home, sondern wirklich das "ganze" System.
Zum Zweiten: Das System ist schon Partitioniert (siehe meine Anfangs-Mail).
Genau das habe ich komplett übersehen. Dann ist auch die Sache mit dem CSM hinfällig.
Es geht mir ja nur darum, wohin grub installiert wird.
Nach wie vor in den Bootsektor der ersten SSD, von der gebootet werden soll. Also quasi die Entsprechung von bspw. /dev/sda bei klassischen SATA- Festplatten/SSDs.
Warum CSM aktivieren, wird davon nicht abgeraten?
Wenn Dein System, wie Du erwähnt hast, bereits im UEFI-Modus installiert wurde, würde ich es jebenfalls _nicht_ aktivieren. Ach ja. Secure Boot sollte auch abgeschaltet sein/werden. openSUSE unterstützt dieses Feature zwar, aber es kommt in Verbindung hiermit immer wieder zu Problemen. Und die kommerziellen nVidia-Kerneltreibermodule funktionieren damit auch nicht.
--
MfG Richi Hallo Richard,
habe jetzt mal im Bios des neuen Rechners nachgesehen. Es ist ein Gigabyte. Unter der Rubrik Bios steht u.a.: Sicherheitsoptionen: System Windows 8/10-Funktion: Windows 8/10 CSM-Unterstützung: Eingeschaltet Other PCI devices: UEFI Das ist vom Hardwarelieferanten (einer der sich auf dem Vertrieb von linuxtauglichen Rechnern, aus dem schwäbischen Bayern, spezialisiert hat). Wenn ich so in der c't über Linux und UEFI lese, was ich alles nicht immer verstehe, ist doch eher die Empfehlung CSM aus, oder? Wenn man nur alle 10 Jahre einen Rechner tauscht, wird man mit den Änderungen, die auch nicht durch Linux angestoßen wurden, überfahren :-( Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.04.2019 um 10:29 schrieb Herbert Albert: [ ... ]
habe jetzt mal im Bios des neuen Rechners nachgesehen. Es ist ein Gigabyte. Unter der Rubrik Bios steht u.a.: Sicherheitsoptionen: System Windows 8/10-Funktion: Windows 8/10 CSM-Unterstützung: Eingeschaltet Other PCI devices: UEFI
Das ist vom Hardwarelieferanten (einer der sich auf dem Vertrieb von linuxtauglichen Rechnern, aus dem schwäbischen Bayern, spezialisiert hat).
Wenn ich so in der c't über Linux und UEFI lese, was ich alles nicht immer verstehe, ist doch eher die Empfehlung CSM aus, oder? Wenn Du einen Artikel vom Oktober 2018 ansprichst, würde ich eher sagen, Hände weg vom Mischbetrieb. Und genau diesen hast Du ja. UEFI aktiv und CSM auch. Das kann die meisten Probleme bereiten. Ich selbst habe (leider?) keinerlei Erfahrung mit UEFI, als ich meinen letzten Notebook einzurichten hatte, wollte ich es mit UEFI versuchen, hatte aber mangels geeignetem Bootmedium (der NB hat kein DVD Laufwerk) nicht mit UEFI geklappt, also habe ich kurzerhand es wieder in die Tonne getreten und auf die klassische Art gewechselt.
Mir persönlich ist das UEFI nach wie vor total suspekt. Allein die Tatsache, dass es nicht garantiert wird, dass ein installiertes System wegen UEFI bei einem Mainboard Tausch wieder bootet, finde ich absolut gruselig. In diesem c't Artikel fand ich im Grunde genommen mehr Negatives als Positives, was für UEFI spräche. Ich weiß natürlich auch, dass eine Diskussion darüber müßig ist, denn der Zug ist schon längst abgefahren.
Wenn man nur alle 10 Jahre einen Rechner tauscht, wird man mit den Änderungen, die auch nicht durch Linux angestoßen wurden, überfahren :-(
Tja, so etwas nennt man Fortschritt Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Sonntag, 7. April 2019, 14:02:43 CEST schrieb Manfred Kreisl:
Am 07.04.2019 um 10:29 schrieb Herbert Albert:
[ ... ]
habe jetzt mal im Bios des neuen Rechners nachgesehen. Es ist ein Gigabyte. Unter der Rubrik Bios steht u.a.: Sicherheitsoptionen: System Windows 8/10-Funktion: Windows 8/10 CSM-Unterstützung: Eingeschaltet Other PCI devices: UEFI
Das ist vom Hardwarelieferanten (einer der sich auf dem Vertrieb von linuxtauglichen Rechnern, aus dem schwäbischen Bayern, spezialisiert hat).
Wenn ich so in der c't über Linux und UEFI lese, was ich alles nicht immer verstehe, ist doch eher die Empfehlung CSM aus, oder?
Wenn Du einen Artikel vom Oktober 2018 ansprichst, würde ich eher sagen, Hände weg vom Mischbetrieb. Nein, ich meinte die Beiträge zu FAQ in der 8/19
Und genau diesen hast Du ja. UEFI aktiv und CSM auch. Das kann die meisten Probleme bereiten. Ist halt so vom Hardwarelieferanten (Namhafter Linux-Schrauber aus dem schwäbischen Bayern) zu eingestellt worden oder ungesehen vom Bioshersteller übernommen worden.
Ich selbst habe (leider?) keinerlei Erfahrung mit UEFI, als ich meinen letzten Notebook einzurichten hatte, wollte ich es mit UEFI versuchen, hatte aber mangels geeignetem Bootmedium (der NB hat kein DVD Laufwerk) nicht mit UEFI geklappt, also habe ich kurzerhand es wieder in die Tonne getreten und auf die klassische Art gewechselt.
Mir persönlich ist das UEFI nach wie vor total suspekt. Allein die Tatsache, dass es nicht garantiert wird, dass ein installiertes System wegen UEFI bei einem Mainboard Tausch wieder bootet, finde ich absolut gruselig.
In diesem c't Artikel fand ich im Grunde genommen mehr Negatives als Positives, was für UEFI spräche. Ich weiß natürlich auch, dass eine Diskussion darüber müßig ist, denn der Zug ist schon längst abgefahren.
Wenn man nur alle 10 Jahre einen Rechner tauscht, wird man mit den Änderungen, die auch nicht durch Linux angestoßen wurden, überfahren :-(
Tja, so etwas nennt man Fortschritt
Manfred
Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 08.04.2019 um 19:14 schrieb Herbert Albert:
Am Sonntag, 7. April 2019, 14:02:43 CEST schrieb Manfred Kreisl:
Am 07.04.2019 um 10:29 schrieb Herbert Albert:
[ ... ]
habe jetzt mal im Bios des neuen Rechners nachgesehen. Es ist ein Gigabyte. Unter der Rubrik Bios steht u.a.: Sicherheitsoptionen: System Windows 8/10-Funktion: Windows 8/10 CSM-Unterstützung: Eingeschaltet Other PCI devices: UEFI
Das ist vom Hardwarelieferanten (einer der sich auf dem Vertrieb von linuxtauglichen Rechnern, aus dem schwäbischen Bayern, spezialisiert hat).
Wenn ich so in der c't über Linux und UEFI lese, was ich alles nicht immer verstehe, ist doch eher die Empfehlung CSM aus, oder?
Wenn Du einen Artikel vom Oktober 2018 ansprichst, würde ich eher sagen, Hände weg vom Mischbetrieb. Nein, ich meinte die Beiträge zu FAQ in der 8/19
Aha, soweit bin ich noch nicht gekommen mit dem Lesen ;)
Und genau diesen hast Du ja. UEFI aktiv und CSM auch. Das kann die meisten Probleme bereiten. Ist halt so vom Hardwarelieferanten (Namhafter Linux-Schrauber aus dem schwäbischen Bayern) zu eingestellt worden oder ungesehen vom Bioshersteller übernommen worden.
Lt. den von mir erwähnten Artikel kann es unter gewissen Umständen vorkommen, dass das Bios automatisch (!) den CSM Mode aktiviert. Das ist gerade das teuflische an der Sache. Da muss also nicht unbedingt der Lieferant dran schuld sein. Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Manfred, Zitat von Manfred Kreisl <ml4km@arcor.de>:
Am 08.04.2019 um 19:14 schrieb Herbert Albert:
Am Sonntag, 7. April 2019, 14:02:43 CEST schrieb Manfred Kreisl:
Am 07.04.2019 um 10:29 schrieb Herbert Albert:
[ ... ]
habe jetzt mal im Bios des neuen Rechners nachgesehen. Es ist ein Gigabyte. Unter der Rubrik Bios steht u.a.: Sicherheitsoptionen: System Windows 8/10-Funktion: Windows 8/10 CSM-Unterstützung: Eingeschaltet Other PCI devices: UEFI
Das ist vom Hardwarelieferanten (einer der sich auf dem Vertrieb von linuxtauglichen Rechnern, aus dem schwäbischen Bayern, spezialisiert hat).
Wenn ich so in der c't über Linux und UEFI lese, was ich alles nicht immer verstehe, ist doch eher die Empfehlung CSM aus, oder?
Wenn Du einen Artikel vom Oktober 2018 ansprichst, würde ich eher sagen, Hände weg vom Mischbetrieb. Nein, ich meinte die Beiträge zu FAQ in der 8/19
Aha, soweit bin ich noch nicht gekommen mit dem Lesen ;)
Und genau diesen hast Du ja. UEFI aktiv und CSM auch. Das kann die meisten Probleme bereiten. Ist halt so vom Hardwarelieferanten (Namhafter Linux-Schrauber aus dem schwäbischen Bayern) zu eingestellt worden oder ungesehen vom Bioshersteller übernommen worden.
Lt. den von mir erwähnten Artikel kann es unter gewissen Umständen vorkommen, dass das Bios automatisch (!) den CSM Mode aktiviert. Das ist gerade das teuflische an der Sache.
Da muss also nicht unbedingt der Lieferant dran schuld sein.
In dem Fall habe ich mich erkundigt. Der Bioshersteller schaltet es standardmäßig an und der Rechenlieferant übernimmt das lt. Rückfrage so. Ich habe jetzt das vorinstallierte opensuse leap 15 schon ein wenig konfiguriert, jedoch noch nicht alle meine Pakte nachgezogen. bevor ich das mache, würde ich gerne das System weg sichern um eine Rückfalllösung zu haben. Würde hier ein rsync --stats --progress --numeric-ids -axAhHSP /mnt/alt/ /mnt/neu ausreichen, bzw. würde der Rückweg so auch funktionieren und der Rechner danach wieder booten? /mnt/alt/=/dev/nvme1n1p2 -> das open beschriebene leap /mnt/neu=/dev/sda1 -> Sicherung Die efi-Partition auf dieser SSD wird ja nicht angefasst, nur die /-Partition. Wie gesagt kenne ich mit dem UEFI-zeugs nicht aus. Was würde passieren, wenn ich auf den Sicherungsstand zurück will und dazu alles auf der Partition / lösche und mit den o.g. rsync zurück spiele? Muss hier grub2 neu installiert werden, oder bootet das System auch so? Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 11. April 2019, 09:04:50 CEST schrieb h.albert@odn.de:
Hallo Manfred,
Zitat von Manfred Kreisl <ml4km@arcor.de>:
Am 08.04.2019 um 19:14 schrieb Herbert Albert:
Am Sonntag, 7. April 2019, 14:02:43 CEST schrieb Manfred Kreisl:
Am 07.04.2019 um 10:29 schrieb Herbert Albert:
[ ... ]
habe jetzt mal im Bios des neuen Rechners nachgesehen. Es ist ein Gigabyte. Unter der Rubrik Bios steht u.a.: Sicherheitsoptionen: System Windows 8/10-Funktion: Windows 8/10 CSM-Unterstützung: Eingeschaltet Other PCI devices: UEFI
Das ist vom Hardwarelieferanten (einer der sich auf dem Vertrieb von linuxtauglichen Rechnern, aus dem schwäbischen Bayern, spezialisiert hat).
Wenn ich so in der c't über Linux und UEFI lese, was ich alles nicht immer verstehe, ist doch eher die Empfehlung CSM aus, oder?
Wenn Du einen Artikel vom Oktober 2018 ansprichst, würde ich eher sagen, Hände weg vom Mischbetrieb.
Nein, ich meinte die Beiträge zu FAQ in der 8/19
Aha, soweit bin ich noch nicht gekommen mit dem Lesen ;)
Und genau diesen hast Du ja. UEFI aktiv und CSM auch. Das kann die meisten Probleme bereiten.
Ist halt so vom Hardwarelieferanten (Namhafter Linux-Schrauber aus dem schwäbischen Bayern) zu eingestellt worden oder ungesehen vom Bioshersteller übernommen worden.
Lt. den von mir erwähnten Artikel kann es unter gewissen Umständen vorkommen, dass das Bios automatisch (!) den CSM Mode aktiviert. Das ist gerade das teuflische an der Sache.
Da muss also nicht unbedingt der Lieferant dran schuld sein.
In dem Fall habe ich mich erkundigt. Der Bioshersteller schaltet es standardmäßig an und der Rechenlieferant übernimmt das lt. Rückfrage so.
Ich habe jetzt das vorinstallierte opensuse leap 15 schon ein wenig konfiguriert, jedoch noch nicht alle meine Pakte nachgezogen. bevor ich das mache, würde ich gerne das System weg sichern um eine Rückfalllösung zu haben.
Würde hier ein rsync --stats --progress --numeric-ids -axAhHSP /mnt/alt/ /mnt/neu ausreichen, bzw. würde der Rückweg so auch funktionieren und der Rechner danach wieder booten? /mnt/alt/=/dev/nvme1n1p2 -> das open beschriebene leap /mnt/neu=/dev/sda1 -> Sicherung
Die efi-Partition auf dieser SSD wird ja nicht angefasst, nur die /-Partition. Wie gesagt kenne ich mit dem UEFI-zeugs nicht aus. Was würde passieren, wenn ich auf den Sicherungsstand zurück will und dazu alles auf der Partition / lösche und mit den o.g. rsync zurück spiele? Muss hier grub2 neu installiert werden, oder bootet das System auch so?
Gruß
Herbert Hallo,
habe nun alle meine Pakete auf das System installiert und auch mein /home umgezogen. Bin nun am Einrichten von VirtualBox. Alle meine VirtualBox-Systeme sind mit / home umgezogen. Als VirtualBox habe ich wie auf dem alten Rechner die Pakte von SuSE :~ # zypper se -si virtualbox Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+-----------------------------+--------- +------------------------------------------+-------- +-------------------------- i+ | virtualbox | package | 5.2.22-lp150.4.23.1 | x86_64 | openSUSE-Leap-15.0-Update i+ | virtualbox-host-kmp-default | package | 5.2.22_k4.12.14_lp150.12.25- lp150.4.23.1 | x86_64 | openSUSE-Leap-15.0-Update i+ | virtualbox-qt | package | 5.2.22-lp150.4.23.1 | x86_64 | openSUSE-Leap-15.0-Update installiert. Wenn ich nun ein VirtualBox-System starte, scheidert es an USB > 2.0 Es kommt die Meldung: Implementation of the USB 2.0 controller not found! Because the USB 2.0 controller state is part of the saved VM state, the VM cannot be started. To fix this problem, either install the 'Oracle VM VirtualBox Extension Pack' or disable USB 2.0 support in the VM settings. Note! This error could also mean that an incompatible version of the 'Oracle VM VirtualBox Extension Pack' is installed (VERR_NOT_FOUND). Fehlercode: NS_ERROR_FAILURE (0x80004005) Komponente: ConsoleWrap Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed} Die Gasterweiterung bei den opensuse-Paketen habe ich auf dem alten Rechner auch nicht installiert. Versuche ich eines der Pakete virtualbox-guest-... zu installieren, kommt es zu Abhängigkeitskonflikten. Der neue Rechner hat ja nun USB 3. Was muss ich tun um VirtualBox wieder mit all den bereits installierten Systemen mit USB zu betreiben? Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Samstag, den 20.04.2019, 20:08 +0200 schrieb Herbert Albert:
Es kommt die Meldung: Implementation of the USB 2.0 controller not found! Because the USB 2.0 controller state is part of the saved VM state, the VM cannot be started. To fix this problem, either install the 'Oracle VM VirtualBox Extension Pack' or disable USB 2.0 support in the VM settings. Note! This error could also mean that an incompatible version of the 'Oracle VM VirtualBox Extension Pack' is installed (VERR_NOT_FOUND).
Der neue Rechner hat ja nun USB 3. Was muss ich tun um VirtualBox wieder mit all den bereits installierten Systemen mit USB zu betreiben?
Steht doch genau in der Meldung von VBox. Du brauchst das passende "Oracle VM VirtualBox Extension Pack" für Deine installierte VB-Version. Dann hast Du wieder USB 2.0- und auch USB 3.0-Unterstützung. Alternativ schaltest Du in den Einstellungen jeder Deiner VMs auf USB 1.1 zurück. - -- MfG Richi -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEL3uOiU4ourJELXQ54DdiOpwB5zsFAly7gc8ACgkQ4DdiOpwB 5zvCeRAAiOs7BXfBNjucNOvk1nJPy7foJzyuPxWsjlz+3WoifXTmpPjXFGq1THMQ FJrLvt5b8o6UDNmUFcgSivSZy85F1Ts8Soq6Ipz+Abx21aK2z9XxFA/+E8YbpDxG a+brDSs+icOJ06Y6y6EnabS3si2VbGovMWArQ6yDC7aUe4hrsqr6ExBc+2WvriJK d8buHJs2WMj8SdwX4iTkE53oVrByTHtCa72uztXsnv8tIHz71wRnEotVhSvU97GT FccZil+0QC+MdEiyWbN/2adjTxUpc/P30Vd0ngJr97kx4cwXGG4+qHIZjp+2yGfq LfbgVRKiRrlOkEpPVRVsF0iDp7Ok2p9HZKDogtEOntvgZQUqCcdBiVes6sVwff4V /BeVgNIcSui/qmbjqQxuKbS0c0SvtOA+nRZLpE7mqVbmctTzk6B2t8rdTjiDm5l4 ZMnJSOEPNl6BxFr2yAJE/uVJDxUuU+2LSk74H4JpyssMvvabRJDHY4p0UehLdQTA 1cdt5ab2LTZzQJ0NEgIz6M2Mer+t3x2ZIFcPJVhHI0bRD0OvcdWnU/c8OQfqyR6Y fv4mv3kECa9YPVERFpbZdNdOYljRMheqGZEBfOSTYRigLPUxemYTT3onE92T4Vjz 6wzfyQlzypWVnXwBjvvTQ4IednJFNdlHM7Gs8fO9GkZGmn1nKyU= =4gXk -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Herbert, Am 20.04.19 um 12:08 schrieb Herbert Albert:
Bin nun am Einrichten von VirtualBox. Alle meine VirtualBox-Systeme sind mit / home umgezogen. Als VirtualBox habe ich wie auf dem alten Rechner die Pakte von SuSE :~ # zypper se -si virtualbox Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository ---+-----------------------------+--------- +------------------------------------------+-------- +-------------------------- i+ | virtualbox | package | 5.2.22-lp150.4.23.1 | x86_64 | openSUSE-Leap-15.0-Update i+ | virtualbox-host-kmp-default | package | 5.2.22_k4.12.14_lp150.12.25- lp150.4.23.1 | x86_64 | openSUSE-Leap-15.0-Update i+ | virtualbox-qt | package | 5.2.22-lp150.4.23.1 | x86_64 | openSUSE-Leap-15.0-Update installiert.
Wenn ich nun ein VirtualBox-System starte, scheidert es an USB > 2.0 Es kommt die Meldung: Implementation of the USB 2.0 controller not found! Because the USB 2.0 controller state is part of the saved VM state, the VM cannot be started. To fix this problem, either install the 'Oracle VM VirtualBox Extension Pack' or disable USB 2.0 support in the VM settings. Note! This error could also mean that an incompatible version of the 'Oracle VM VirtualBox Extension Pack' is installed (VERR_NOT_FOUND).
Fehlercode: NS_ERROR_FAILURE (0x80004005) Komponente: ConsoleWrap Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}
Die Gasterweiterung bei den opensuse-Paketen habe ich auf dem alten Rechner auch nicht installiert. Versuche ich eines der Pakete virtualbox-guest-... zu installieren, kommt es zu Abhängigkeitskonflikten.
Der neue Rechner hat ja nun USB 3. Was muss ich tun um VirtualBox wieder mit all den bereits installierten Systemen mit USB zu betreiben?
Wenn ich das richtig sehe, musst du dir bei Virtualbox.org die passende Version der des VirtualBox Extension Pack herunterladen und über den Virtualbox Manager installieren: Datei -> Einstellungen -> Zusatzpakete, dann auf das + oben rechts klicken und im aufpoppenden Dateimanagerfenster die heruntergeladene Datei auswählen. Nach der Installation und dem Start einer virtuellen Maschine solltest du dieses ISO-Image unter Geräte -> Optische Laufwerke VBoxGuestAdditions_versionXXX.iso sehen können. (Irgendwo auf den VB-Seiten gibt's auch eine Anleitung). Die Installation ist auf jeden Fall ganz einfach). Dieses Paket wird m. W. bei opensuse nicht angeboten, da die Installation ohnehin nicht über YaST oder Zypper, sondern über besagten Manager läuft. Gruß, Michael -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Samstag, den 20.04.2019, 14:39 -0600 schrieb Michael Eschweiler:
Nach der Installation und dem Start einer virtuellen Maschine solltest du dieses ISO-Image unter Geräte -> Optische Laufwerke VBoxGuestAdditions_versionXXX.iso sehen können.
Das Extension Pack hat mit den Gasterweiterungen nichts zu tun.
Dieses Paket wird m. W. bei opensuse nicht angeboten, da die Installation ohnehin nicht über YaST oder Zypper, sondern über besagten Manager läuft.
Es wird nicht angeboten, da es unter einer pröprietären Lizenz steht und nur für private- als auch Evaluierungszwecke kostenfrei genutzt werden kann. Nutzt man es gewerblich bzw. produktiv in einem Unternehmen, müssen hierfür Lizenzen bei Oracle erworben werden. - -- MfG Richi -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEL3uOiU4ourJELXQ54DdiOpwB5zsFAly7hhwACgkQ4DdiOpwB 5zuXTRAAiGRxzTCCQ4Ur6kCKLTq5ii205NolHBEesMtkD0p1hVfO93Fj2FgNW7PA RyZuqyl5cP/DzS5ylzKyZ63JiGFB5CheCI3TmHUPDy2sEqxLSlhmr4pDTkF4W8tf WHyQT92qIFXkBsgt0EhCzW7EXx0DfsBxywATXhQCgmwYDFe44mLThmwS4MY6ESNU zscFS2jyz0zZ4S5URPY0loU+OfNwLKMcDtEwbETPEaASevu0H9rOM0bYJZmNxEEt RKwGWswe3SgBYH4eZoPrljH6O6U5LoCENFVFK3596oyA19U+3XWtZXAZxPowIXCh QCCf2UHL80Z7J3brwMKvW6ZyrCS89mQKFN9SMLCkE3ODD7dSW9nDPcncqQdyiaqh KOt3H5kDESEE6uhwhMFQkccwOJ9zJ4ONW1qh2WQf9q/L4alceAif66z7z9CirQ5c v8nqrbnibPtcJ9SlPJxnuyPgmVLGZN5J85txNUCEOvhJA/1wm8Mev+iEaGucS/V0 sNG8cBNmfRFC0EvA54dB742elIZRArn3CuCgop3SS4bL/tPEAMolZ0R30wSJumvf 9bUXIUW8Fy5Gs2vOsxHl45gDcYkO4KbPh5pWZcfIjCvw5cE98JaTD9qWi/AGXjf2 MF+irpTussGM0m6+JbMp3LNqXJ/ww+azOi4cJ7WknNEGGlAA/CA= =Aet0 -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Richard, Am 20.04.19 um 14:50 schrieb Richard Kraut:
Am Samstag, den 20.04.2019, 14:39 -0600 schrieb Michael Eschweiler:
Nach der Installation und dem Start einer virtuellen Maschine solltest du dieses ISO-Image unter Geräte -> Optische Laufwerke VBoxGuestAdditions_versionXXX.iso sehen können.
Das Extension Pack hat mit den Gasterweiterungen nichts zu tun.
Aber das Extension Pack ist doch für die Unterstützung von USB erforderlich, oder? Jedenfalls ist's bei mir so, dass erst nach der Installation des Extension Packs USB-Unterstützung funktioniert... Bei mir sind die Pakete virtualbox virtualbox-host-kmp-default virtual-qt installiert, und wie Herbert wollte ich für die USB-Unterstützung zunächst guest-tools etc. installieren. Das ging aber wegen Konflikten nicht. Erst danach habe ich mich daran erinnert, dass es das Extension Pack sein muss...
Dieses Paket wird m. W. bei opensuse nicht angeboten, da die Installation ohnehin nicht über YaST oder Zypper, sondern über besagten Manager läuft.
Es wird nicht angeboten, da es unter einer pröprietären Lizenz steht und nur für private- als auch Evaluierungszwecke kostenfrei genutzt werden kann. Nutzt man es gewerblich bzw. produktiv in einem Unternehmen, müssen hierfür Lizenzen bei Oracle erworben werden.
Ist das tatsächlich der Grund? Dann wäre es naheliegend, zu vermuten, dass das Paket bei non-oss zu finden wäre, aber das ist es nicht... Gruß, Michael
Hallo Michael,
Hallo Richard,
Am 20.04.19 um 14:50 schrieb Richard Kraut:
Am Samstag, den 20.04.2019, 14:39 -0600 schrieb Michael Eschweiler:
Nach der Installation und dem Start einer virtuellen Maschine solltest du dieses ISO-Image unter Geräte -> Optische Laufwerke VBoxGuestAdditions_versionXXX.iso sehen können.
Das Extension Pack hat mit den Gasterweiterungen nichts zu tun.
Aber das Extension Pack ist doch für die Unterstützung von USB erforderlich, oder? Jedenfalls ist's bei mir so, dass erst nach der Installation des Extension Packs USB-Unterstützung funktioniert...
Das "Extension Pack" ist eine Erweiterung von VirtualBox. Es enthält, wie Richard schon schrieb, die Komponeneten von VirtualBox, die nicht frei sind. Dazu gehört u.a. die Unterstützung von USB >1. Es ist also eine Erweiterung der auf dem Host laufenden Software, während die "Gasterweiterungen" diejenige Software enthalten, die (wie der Name schon sagt) auf dem Gast laufen. Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@web.de / ________________________________/ -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Sonntag, 21. April 2019, 08:50:11 CEST schrieb Michael Höhne:
Hallo Michael,
Hallo Richard,
Am 20.04.19 um 14:50 schrieb Richard Kraut:
Am Samstag, den 20.04.2019, 14:39 -0600 schrieb Michael Eschweiler:
Nach der Installation und dem Start einer virtuellen Maschine solltest du dieses ISO-Image unter Geräte -> Optische Laufwerke VBoxGuestAdditions_versionXXX.iso sehen können.
Das Extension Pack hat mit den Gasterweiterungen nichts zu tun.
Aber das Extension Pack ist doch für die Unterstützung von USB erforderlich, oder? Jedenfalls ist's bei mir so, dass erst nach der Installation des Extension Packs USB-Unterstützung funktioniert...
Das "Extension Pack" ist eine Erweiterung von VirtualBox. Es enthält, wie Richard schon schrieb, die Komponeneten von VirtualBox, die nicht frei sind. Dazu gehört u.a. die Unterstützung von USB >1.
Es ist also eine Erweiterung der auf dem Host laufenden Software, während die "Gasterweiterungen" diejenige Software enthalten, die (wie der Name schon sagt) auf dem Gast laufen.
Gruß, Michael Hallo Michael,
jetzt wird es etwas klarer. Historisch habe ich bis leap 42 immer die Pakete von Oracle verwendet, also das RPM und das Extension Pack. Musste dann halt bei jedem neuen Kernel den Befehl "/etc/init.d/vboxdrv setup" ausführen. Warum ich beim Wechsel auf leap 15 auf die opensuse eigenen Pakete umgestiegen bin, kann ich nicht mehr auf die Schnelle nachvollziehen. Ich hatte da einen Thread auf der Liste und mir wurde zu den Suse-Paketen geraden. Das Verfahren bis dahin war: RPM installieren, dann mit Root-Rechten im VirtualBox-Manager das Extension-Pack installieren. Für den jeweiligen Gast konnte man dann das ISO-Image für die Gasterweiterung auf das CD-Laufwerk legen und in dem jeweiligen Betriebssystem installieren. Das mit dem Extension-Pack habe ich dann mit dem Wechsel irgendwie aus den Augen verloren. Auf dem alten Rechner läuft VirtualBox 5.2.22. Als Extension Pack ist aber noch 5.2.14 installiert, welches wohl noch aus der Zeit vor der Umstellung stammt. Einschränkungen habe ich nicht bemerkt. Die Gasterweiterung habe ich dann aus dem Menü der Gast-Session -> Geräte -> Gasterweiterung einlegen geholt, da ein Rechtsklick auf das CD-Symbol das ISO nicht mehr angezeigt hat. Also habe ich gelernt, wenn man alle Funktionalitäten haben will, muss man aktiv zu den SuSE-Paketen noch das Extension Pack downloaden und installieren. Wie ich gesehen habe gibt es auf der Oracle Seite für die 5er bereits VirtualBox 5.2.28, mit entsprechenden Extension Pack. Dann gibt es ja auch schon VirtualBox 6. Es gibt also, wie ich das sehe 3 Möglichkeiten. a) händisch rpm und Extension Pack installieren b) openssuse OSS + Extension Pack händisch installieren c) Repo einbinden und wohl auch das Extension Pack dazu installieren (?) [virtualbox] name=VirtualBox for openSUSE $releasever - $basearch baseurl=http://download.virtualbox.org/virtualbox/rpm/opensuse/$releasever/ $basearch. Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Sonntag, 21. April 2019, 10:40:41 CEST schrieb Herbert Albert:
Am Sonntag, 21. April 2019, 08:50:11 CEST schrieb Michael Höhne:
Hallo Michael,
Hallo Richard,
Am 20.04.19 um 14:50 schrieb Richard Kraut:
Am Samstag, den 20.04.2019, 14:39 -0600 schrieb Michael Eschweiler:
Nach der Installation und dem Start einer virtuellen Maschine solltest du dieses ISO-Image unter Geräte -> Optische Laufwerke VBoxGuestAdditions_versionXXX.iso sehen können.
Das Extension Pack hat mit den Gasterweiterungen nichts zu tun.
Aber das Extension Pack ist doch für die Unterstützung von USB erforderlich, oder? Jedenfalls ist's bei mir so, dass erst nach der Installation des Extension Packs USB-Unterstützung funktioniert...
Das "Extension Pack" ist eine Erweiterung von VirtualBox. Es enthält, wie Richard schon schrieb, die Komponeneten von VirtualBox, die nicht frei sind. Dazu gehört u.a. die Unterstützung von USB >1.
Es ist also eine Erweiterung der auf dem Host laufenden Software, während die "Gasterweiterungen" diejenige Software enthalten, die (wie der Name schon sagt) auf dem Gast laufen.
Gruß, Michael
Hallo Michael,
jetzt wird es etwas klarer. Historisch habe ich bis leap 42 immer die Pakete von Oracle verwendet, also das RPM und das Extension Pack. Musste dann halt bei jedem neuen Kernel den Befehl "/etc/init.d/vboxdrv setup" ausführen. Warum ich beim Wechsel auf leap 15 auf die opensuse eigenen Pakete umgestiegen bin, kann ich nicht mehr auf die Schnelle nachvollziehen. Ich hatte da einen Thread auf der Liste und mir wurde zu den Suse-Paketen geraden.
Das Verfahren bis dahin war: RPM installieren, dann mit Root-Rechten im VirtualBox-Manager das Extension-Pack installieren. Für den jeweiligen Gast konnte man dann das ISO-Image für die Gasterweiterung auf das CD-Laufwerk legen und in dem jeweiligen Betriebssystem installieren.
Das mit dem Extension-Pack habe ich dann mit dem Wechsel irgendwie aus den Augen verloren. Auf dem alten Rechner läuft VirtualBox 5.2.22. Als Extension Pack ist aber noch 5.2.14 installiert, welches wohl noch aus der Zeit vor der Umstellung stammt. Einschränkungen habe ich nicht bemerkt. Die Gasterweiterung habe ich dann aus dem Menü der Gast-Session -> Geräte -> Gasterweiterung einlegen geholt, da ein Rechtsklick auf das CD-Symbol das ISO nicht mehr angezeigt hat.
Also habe ich gelernt, wenn man alle Funktionalitäten haben will, muss man aktiv zu den SuSE-Paketen noch das Extension Pack downloaden und installieren.
Wie ich gesehen habe gibt es auf der Oracle Seite für die 5er bereits VirtualBox 5.2.28, mit entsprechenden Extension Pack. Dann gibt es ja auch schon VirtualBox 6.
Es gibt also, wie ich das sehe 3 Möglichkeiten. a) händisch rpm und Extension Pack installieren b) openssuse OSS + Extension Pack händisch installieren c) Repo einbinden und wohl auch das Extension Pack dazu installieren (?) [virtualbox] name=VirtualBox for openSUSE $releasever - $basearch baseurl=http://download.virtualbox.org/virtualbox/rpm/opensuse/$releasever/ $basearch.
Gruß
Herbert um den thread noch etwas zu strapazieren: Was stellt man bei modernen CPUs (Intel Core i7-9700K) (im Gastsystem unter Prozessor: PAE/NX ein? Beschleunigung: Paravirtualsierung legacy, oder andere? Hardware-Virtualisierung VT-x/AMD-v aktiv und Nested-Paging aktiv?
das wären die Einstellungen aus meiner alten Maschine. Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Fri, 05 Apr 2019 18:04:18 +0200 schrieb Herbert Albert <h.albert@odn.de>:
Also viele Frage, vielleicht bekomme ich zielführende Antworten. Danke.
Dem was Klaus gesagt hat kann ich aus meiner Sicht nicht viel hinzufügen. Bereite die Installation ordentlich vor und lasse Dich nicht von andere oder von Dir selbst unter Zeitdruck setzen. Wenn das neue System läuft kannst Du immer noch ausprobieren was passiert, wenn Du die alte Installation anpassen willst. Aber erst den neuen Rechner fertig machen. -- MfG Jan-Uwe Kögel
Am Samstag, 6. April 2019, 19:07:00 CEST schrieben Sie:
Am Fri, 05 Apr 2019 18:04:18 +0200
schrieb Herbert Albert <h.albert@odn.de>:
Also viele Frage, vielleicht bekomme ich zielführende Antworten. Danke.
Dem was Klaus gesagt hat kann ich aus meiner Sicht nicht viel hinzufügen. Bereite die Installation ordentlich vor und lasse Dich nicht von andere oder von Dir selbst unter Zeitdruck setzen. Wenn das neue System läuft kannst Du immer noch ausprobieren was passiert, wenn Du die alte Installation anpassen willst. Aber erst den neuen Rechner fertig machen. Na ja, eine Grundinstallation von opensuse leap 15 war auf dem Rechner schon drauf. Könnte jetzt meine Repos umziehen und auf dem alten Rechner z.B. mit Yast meine installierten Pakete in eine Datei schreiben und dann auf dem neuen Rechner einlesen und ggf. Abhängigkeits-Konflikte lösen.
Hat das schon jemand gemacht? Herbert PS: Ist versehentlich zur erst an den falschen Absender raus. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Herbert, hallo zusammen, Am Samstag, 6. April 2019, 22:13:31 CEST schrieb Herbert Albert:
Könnte jetzt meine Repos umziehen und auf dem alten Rechner z.B. mit Yast meine installierten Pakete in eine Datei schreiben und dann auf dem neuen Rechner einlesen und ggf. Abhängigkeits-Konflikte lösen.
Hat das schon jemand gemacht?
Muss es unbedingt YaST sein? ;-) rpm -qa --qf '%{name}\n' | grep -v '^lib[^r][^e][^o]' | sort > paketliste-alter-rechner Das grep -v entfernt lib*-Pakete außer libreoffice aus der Liste -die werden per Abhängigkeiten installiert. Evtl. musst Du noch ein paar libre*-Pakete, die nichts mit libreoffice zu tun haben (z. B. libreadline8) manuell aus er Liste löschen. Dann auf dem neuen Rechner zypper in `cat paketliste-alter-rechner` Noch ein Tip zu Config-Dateien: Ich habe mir angewöhnt, bei Änderungen in /etc/ vor dem Bearbeiten einer Datei eine Kopie namens (z. B.) irgendwas_ORIG-2019-04-07 anzulegen. Das hat zwei Vorteile: - find -name '*ORIG*' gibt mir eine Liste der manuell geänderten Dateien - ich kann gegen die *ORIG*-Dateien diffen, um meine Änderungen nachzuvollziehen Noch konsequenter und besser wäre es, alle geänderten Dateien, installierten Pakete etc. per Konfigurationsmanagement (z. B. Salt) zu managen. Bei Servern mache ich das auch (und bereue, es nicht schon vor Jahren angefangen zu haben), aber für meinen Laptop war es mir etwas zu viel Aufwand ;-) Gruß Christian Boltz --
Wow consensus in less than 24 hours....imagine if it always worked that way....:-) Something smells fishy here ;-) Do you have the solution(tm) for the "Kanzlerfrage"? :) [>> Peter Flodin, > Andreas Jäger und Christoph Thiel in opensuse]
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Zitat von Christian Boltz <suse@cboltz.de>:
Hallo Herbert, hallo zusammen,
Am Samstag, 6. April 2019, 22:13:31 CEST schrieb Herbert Albert:
Könnte jetzt meine Repos umziehen und auf dem alten Rechner z.B. mit Yast meine installierten Pakete in eine Datei schreiben und dann auf dem neuen Rechner einlesen und ggf. Abhängigkeits-Konflikte lösen.
Hat das schon jemand gemacht?
Muss es unbedingt YaST sein? ;-)
rpm -qa --qf '%{name}\n' | grep -v '^lib[^r][^e][^o]' | sort > paketliste-alter-rechner
Das grep -v entfernt lib*-Pakete außer libreoffice aus der Liste -die werden per Abhängigkeiten installiert. Evtl. musst Du noch ein paar libre*-Pakete, die nichts mit libreoffice zu tun haben (z. B. libreadline8) manuell aus er Liste löschen.
Dann auf dem neuen Rechner
zypper in `cat paketliste-alter-rechner`
Noch ein Tip zu Config-Dateien: Ich habe mir angewöhnt, bei Änderungen in /etc/ vor dem Bearbeiten einer Datei eine Kopie namens (z. B.) irgendwas_ORIG-2019-04-07 anzulegen. Das hat zwei Vorteile: - find -name '*ORIG*' gibt mir eine Liste der manuell geänderten Dateien - ich kann gegen die *ORIG*-Dateien diffen, um meine Änderungen nachzuvollziehen
Noch konsequenter und besser wäre es, alle geänderten Dateien, installierten Pakete etc. per Konfigurationsmanagement (z. B. Salt) zu managen. Bei Servern mache ich das auch (und bereue, es nicht schon vor Jahren angefangen zu haben), aber für meinen Laptop war es mir etwas zu viel Aufwand ;-)
Gruß
Christian Boltz --
Wow consensus in less than 24 hours....imagine if it always worked that way....:-) Something smells fishy here ;-) Do you have the solution(tm) for the "Kanzlerfrage"? :) [>> Peter Flodin, > Andreas Jäger und Christoph Thiel in opensuse]
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Christian, warum soll ich die libs nicht importieren, wenn ich doch auf dem alten Rechner ein aktuelles leap 15 habe und auch auf dem neuen Rechner haben will? Ist es der neueren Hardware geschuldet? Yast hat für mich den Vorteil, dass ich interaktiv prüfen kann, also anwählen, abwählen und zwischen drin checken, ob alle Abhängigkeiten erfüllt sind. Bei zypper läuft der Vorgang sequenziell durch. Von /etc würde ich nur einige Dateien, wie sane, cups und samba übernehmen. Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Herbert, hallo zusammen, Am Montag, 8. April 2019, 07:14:26 CEST schrieb h.albert@odn.de:
Zitat von Christian Boltz <suse@cboltz.de>:
rpm -qa --qf '%{name}\n' | grep -v '^lib[^r][^e][^o]' | sort > paketliste-alter-rechner
Das grep -v entfernt lib*-Pakete außer libreoffice aus der Liste -die werden per Abhängigkeiten installiert. Evtl. musst Du noch ein paar libre*-Pakete, die nichts mit libreoffice zu tun haben (z. B. libreadline8) manuell aus er Liste löschen.
warum soll ich die libs nicht importieren, wenn ich doch auf dem alten Rechner ein aktuelles leap 15 habe und auch auf dem neuen Rechner haben will? Ist es der neueren Hardware geschuldet?
Ich hatte beim Stichwort "alter Rechner" und der schon etwas länglichen Diskussion irgendwie übersehen, dass der alte Rechner auch schon mit Leap 15 läuft ;-) In diesem Fall kannst Du die lib*-Pakete grundsätzlich in der Paketliste lassen. Andererseits schadet es auch nicht, sie rauszulöschen - gerade wenn der alte Rechner mehrfach Updates bekommen hat, haben sich da wohl einige inzwischen unnötige Pakete angesammelt. Nochmal andererseits - Plattenplatz kostet ja quasi nix mehr ;-)
Yast hat für mich den Vorteil, dass ich interaktiv prüfen kann, also anwählen, abwählen und zwischen drin checken, ob alle Abhängigkeiten erfüllt sind. Bei zypper läuft der Vorgang sequenziell durch.
Klar, aber zumindest bei den Abhängigkeiten brauchst Du keine Bedenken zu haben, weil zypper die auch prüft. Ob/wie YaST eine Paketliste einlesen kann, musst Du ggf. selbst rausfinden. Klick Dich einfach mal durchs Menü ;-)
Von /etc würde ich nur einige Dateien, wie sane, cups und samba übernehmen.
Klingt sinnvoll. Gruß Christian Boltz -- soviel zu Win. Was hat Dich denn da geritten? Auf Win- Fehlermeldungen würde ich nix geben. Wenn das OS konsequent wäre, würde es sich selbst löschen. [Philipp Zacharias in suse-linux] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Christian, Am Montag, 8. April 2019, 13:06:40 CEST schrieb Christian Boltz:
Hallo Herbert, hallo zusammen,
Am Montag, 8. April 2019, 07:14:26 CEST schrieb h.albert@odn.de:
Zitat von Christian Boltz <suse@cboltz.de>:
rpm -qa --qf '%{name}\n' | grep -v '^lib[^r][^e][^o]' | sort > paketliste-alter-rechner
Das grep -v entfernt lib*-Pakete außer libreoffice aus der Liste -die werden per Abhängigkeiten installiert. Evtl. musst Du noch ein paar libre*-Pakete, die nichts mit libreoffice zu tun haben (z. B. libreadline8) manuell aus er Liste löschen.
warum soll ich die libs nicht importieren, wenn ich doch auf dem alten Rechner ein aktuelles leap 15 habe und auch auf dem neuen Rechner haben will? Ist es der neueren Hardware geschuldet?
Ich hatte beim Stichwort "alter Rechner" und der schon etwas länglichen Diskussion irgendwie übersehen, dass der alte Rechner auch schon mit Leap 15 läuft ;-) Deshalb hatte ich meine Eingangsmail etwas ausführlicher gestaltet um den gesamten Ausgangszustand darzulegen.
In diesem Fall kannst Du die lib*-Pakete grundsätzlich in der Paketliste lassen. Andererseits schadet es auch nicht, sie rauszulöschen - gerade wenn der alte Rechner mehrfach Updates bekommen hat, haben sich da wohl einige inzwischen unnötige Pakete angesammelt. Nochmal andererseits - Plattenplatz kostet ja quasi nix mehr ;-)
Yast hat für mich den Vorteil, dass ich interaktiv prüfen kann, also anwählen, abwählen und zwischen drin checken, ob alle Abhängigkeiten erfüllt sind. Bei zypper läuft der Vorgang sequenziell durch.
Klar, aber zumindest bei den Abhängigkeiten brauchst Du keine Bedenken zu haben, weil zypper die auch prüft.
weiß ich, jedoch durchläuft man die zypper-Abfrage vorn vorne bis hinten und kann nicht nochmals zurückspringen um Änderungen vorzunehmen.
Ob/wie YaST eine Paketliste einlesen kann, musst Du ggf. selbst rausfinden. Klick Dich einfach mal durchs Menü ;-)
geht ganz einfach: Datei importieren.
Von /etc würde ich nur einige Dateien, wie sane, cups und samba übernehmen.
Klingt sinnvoll.
Gruß
Christian Boltz
Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Freitag, den 05.04.2019, 18:04 +0200 schrieb Herbert Albert:
Auf dem Neuen würde es dann so aussehen: # /etc/fstab: static file system information. # # <file sys> <mount point> <type> <options> <dump> <pass>
# device during installation: /dev/nvme0n1p2 UUID=0dd9315b-f57a-41b2-ad39-520ec4274158 / ext4 defaults 0 1
# device during installation: /dev/nvme0n1p1 UUID=483B-7EA5 /boot/efi vfat rw 0 2
# device during installation: /dev/nvme1n1p1 UUID=b3a4c1d0-0710-4edc-bea3-dc84f8ed241f /home ext4 defaults 0 2
# device during installation: /dev/sda1 UUID=7ee633cb-2961-4473-8a88-2484e8780601 /datadisk2 ext4 noauto,user 0 2
# device during installation: /dev/nvme0n1p3 UUID=fbb099fa-8cfe-40ac-afbe-2fcb37b6bbe3 none swap sw 0 0 Die beiden /backup und /backup2 wandern in die HDD: UUID=7ee633cb-2961-4473- 8a88- 2484e8780601 /dev/sr0 /media/cdrom0 udf,i so9660 ro,user,noauto 0 0
Du willst also richtig im UEFI-Modus starten? Das habe ich meiner anderen E- Mail nicht berücksichtigt.
Danach sollte ich wohl auf der Kopie in der Datei /boot/grub2/grub.cfg die UUIDs tauschen, wohl am Besten mit suchen & ersetzen. also (/ alt) 59259677-fb46-4b39-a7cd-72a2e0687277 -> (/ neu) 0dd9315b-f57a-41b2-ad39-520ec4274158 Ist das korrekt so? Muss ich noch einen Datei anpassen?
Du benötigst für den UEFI-Boot die Grub2-Variante mit dem entsprechendem Support. Wenn Deine Rechner bisher noch immer mit einem alten BIOS liefen, ist die benötigte Variante jedenfalls nicht installiert. Zusätzlich wird noch der 'efibootmgr' und 'shim' benötigt. Und denke daran, dass die /boot/grub2/grub.cfg automatisch überschrieben wird.
Worin ich mich gar nicht auskenne ist die Sache mit dem UEFI. Wenn ich bisher ein System umgezogen habe, habe ich zuerst von einer DVD oder Stick gebootet, dann mount /dev/nvme1n1p2 /mnt mount --bind /dev /mnt/dev mount --bind /sys /mn/sys mount --bind /proc /mnt/proc chroot /mnt
und jetzt kommt die Frage, wohin zeigt grub2-install? In die EFI Partition /dev/nvme1n1p1, also grub2-install /dev/nvme1n1p1? grub2-mkconfig -o /boot/grub2/grub.cfg
Auf die erste SSD, von der gebootet werden soll. Im optimalen Fall ist das auch die SSD, welche das EFI-Bootverzeichnis mit dem eigentlichem UEFI- Bootloader (/boot/efi) enthält.
Da in dem Neuen Rechner eine neuere, leistungsstärkere Nvidia-Karte steckt, muss ich diese [...snip...] ersetzen. Mache ich wohl am Besten mit einem Yast in der Konsole, falls X nicht läuft, oder gibt es da auch einen zypper Befehl?
Sollte beides gehen, also via Ncurses-YaST sowie via zypper. Im Zweifel die Manpage lesen. Es gibt aber auch eine Kernel-Bootoption, welche den X-Server zumindest in einer rudimentären VESA-Auflösung starten sollte -> 'x11failsafe'.
Frage ist dann noch, ob die neue Netzwerkkarte mit der alten Konfiguration läuft, oder ob ich da auf der Kopie auch noch eine datei editieren muss, vor dem Kopieren auf das Zielsystem?
Wenn, dann eher nach dem kopieren und starten des Systems auf dem neuen Rechner. Die neue Hardware wird ja dann erst neu erkannt etc. - -- MfG Richi -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEL3uOiU4ourJELXQ54DdiOpwB5zsFAlypB5UACgkQ4DdiOpwB 5zu6oxAAp7UWMtRP4AsKw6mXwlvq+Yi0t6bI7+eJuze162ALJfVtc68ngV+PF+Mk oKObYa2kv4JVYuBX+H3I1cJEXGLMOGEIvW/WOboDb+am256z+lJmd0Hg9T5vOdt2 K/ByL5mjhgfJ+qk3AeU8HHaqJKXOyUAv5ioC3FdZtTwXKNAUgHsHLM1/vw7rsx+E z7ILIJwE9bDKD97xQ2zz0wyvxFNcG1QmwHbryHwiPc5VNLiPKp+HSrLXAPPpDOVU 4TgbPl7VQjFwVPXTw+VjHNN7NjMvXkYamJt7FxY3n8EwjaYjZoML2mZ4coU6NTqX EUX4RNRtvvfkeibf6u1qJdESeloMKEU/L5r+wlvmbesTmlFcfm+9NfuuH0iiW9eG U9UzuJOI9eNOvzvmPK8hFVj91zMDLjsO1TA+Pfmsl6eXHpjemp3ueWDa0qPA2LWb 5XL/ra25VTetjVb9UGRVojllJiBloBdjZn7w2QbAHuSV8JqvrNUErpQ0/S4NhdGO 0NAKLkfK3d5DtH+KC3oWDPS4S1nFi7etzciPkjw04s/GUBw6j07eIhEJKs195z53 UtLVZLM88XPvOOuT9ZD76hFvF+54pIsAVf667vMHFfuqeHLkCHpq2pBvXJkM5pop SdyRh87LwVb6PMBQ6PBrkdH+3wSWobijZ2tOWXuOKaQqNQbpDw8= =sFIs -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Samstag, 6. April 2019, 22:10:01 CEST schrieb Richard Kraut:
Am Freitag, den 05.04.2019, 18:04 +0200 schrieb Herbert Albert:
Auf dem Neuen würde es dann so aussehen: # /etc/fstab: static file system information. # # <file sys> <mount point> <type> <options> <dump> <pass>
# device during installation: /dev/nvme0n1p2 UUID=0dd9315b-f57a-41b2-ad39-520ec4274158 / ext4 defaults 0 1
# device during installation: /dev/nvme0n1p1 UUID=483B-7EA5 /boot/efi vfat rw 0 2
# device during installation: /dev/nvme1n1p1 UUID=b3a4c1d0-0710-4edc-bea3-dc84f8ed241f /home ext4 defaults 0 2
# device during installation: /dev/sda1 UUID=7ee633cb-2961-4473-8a88-2484e8780601 /datadisk2 ext4 noauto,use r 0 2
# device during installation: /dev/nvme0n1p3 UUID=fbb099fa-8cfe-40ac-afbe-2fcb37b6bbe3 none swap sw 0 0 Die beiden /backup und /backup2 wandern in die HDD: UUID=7ee633cb-2961-4473- 8a88- 2484e8780601 /dev/sr0 /media/cdrom0 udf ,i so9660 ro,user,noauto 0 0
Du willst also richtig im UEFI-Modus starten? Das habe ich meiner anderen E- Mail nicht berücksichtigt.
Danach sollte ich wohl auf der Kopie in der Datei /boot/grub2/grub.cfg die UUIDs tauschen, wohl am Besten mit suchen & ersetzen. also (/ alt) 59259677-fb46-4b39-a7cd-72a2e0687277 -> (/ neu) 0dd9315b-f57a-41b2-ad39-520ec4274158 Ist das korrekt so? Muss ich noch einen Datei anpassen?
Du benötigst für den UEFI-Boot die Grub2-Variante mit dem entsprechendem Support. Wenn Deine Rechner bisher noch immer mit einem alten BIOS liefen, ist die benötigte Variante jedenfalls nicht installiert. Zusätzlich wird noch der 'efibootmgr' und 'shim' benötigt. Und denke daran, dass die /boot/grub2/grub.cfg automatisch überschrieben wird.
Worin ich mich gar nicht auskenne ist die Sache mit dem UEFI. Wenn ich bisher ein System umgezogen habe, habe ich zuerst von einer DVD oder Stick gebootet, dann mount /dev/nvme1n1p2 /mnt mount --bind /dev /mnt/dev mount --bind /sys /mn/sys mount --bind /proc /mnt/proc chroot /mnt
und jetzt kommt die Frage, wohin zeigt grub2-install? In die EFI Partition /dev/nvme1n1p1, also grub2-install /dev/nvme1n1p1? grub2-mkconfig -o /boot/grub2/grub.cfg
Auf die erste SSD, von der gebootet werden soll. Im optimalen Fall ist das auch die SSD, welche das EFI-Bootverzeichnis mit dem eigentlichem UEFI- Bootloader (/boot/efi) enthält.
Da in dem Neuen Rechner eine neuere, leistungsstärkere Nvidia-Karte steckt, muss ich diese
[...snip...]
ersetzen. Mache ich wohl am Besten mit einem Yast in der Konsole, falls X nicht läuft, oder gibt es da auch einen zypper Befehl?
Sollte beides gehen, also via Ncurses-YaST sowie via zypper. Im Zweifel die Manpage lesen. Es gibt aber auch eine Kernel-Bootoption, welche den X-Server zumindest in einer rudimentären VESA-Auflösung starten sollte -> 'x11failsafe'.
Frage ist dann noch, ob die neue Netzwerkkarte mit der alten Konfiguration läuft, oder ob ich da auf der Kopie auch noch eine datei editieren muss, vor dem Kopieren auf das Zielsystem?
Wenn, dann eher nach dem kopieren und starten des Systems auf dem neuen Rechner. Die neue Hardware wird ja dann erst neu erkannt etc.
--
MfG Richi
Hallo Richard, klingt für mich etwas kompliziert. Mit den neuen UEFI-Zeugs habe ich noch Null Erfahrung. Da auf dem neuem Rechner schon eine Grundinstallation von opensuse leap 15 ist könnte ich auch folgendes machen: /home auf /home des neuen Rechners umziehen auf dem neuen Rechner mittels Yast alle User mit den gleichen Einstellungen (uid etc.) anlegen die Repos des Alten auf den neuen kopieren und die Paketliste des alten mit Yast auf den Neuen einlesen. In Yast "alle aktualisieren, falls neuere vorhanden" o.s.ä. Falls Abhängigkeitsprobleme auftreten irgendwie lösen. Und dann kann ich nur die Altprogramme umziehen, von denen ich noch die rpm- Pakte habe und muss sehen, dass ich wieder die erforderlichen libs als rpm- Pakte auftreibe. Dann folgt halt noch die Konfiguration von Druckern, Scannern, usw. Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Freitag, 5. April 2019, 18:04:18 CEST schrieb Herbert Albert:
Hallo,
ich will mein opensuse leap 15 von einen (sehr) alten Rechner ohne UEFI auf einen neuen mit UEFI-Bios umziehe.
Im alten Rechner sind / und /home auf getrennten Partitionen /etc/fstab UUID=498b4168-3b86-4375-8d73-69ce91714f5f swap swap defaults 0 0 UUID=b55a273e-deac-4264-ac1a-9c37843f6678 swap swap defaults 0 0 UUID=59259677-fb46-4b39-a7cd-72a2e0687277 / ext4 acl,user_xattr 1 1 UUID=6dc1df34-cca3-47dd-9be3-4626afcb5a94 /home xfs defaults 1 2 /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246JDWSA65315-part1 /backup ext3 acl,user_xattr 1 1 /dev/disk/by-id/ata-ST3500413AS_Z2A8HWPT-part1 /backup2 ext4 acl,user_xattr 1 2
Auf dem Neuen würde es dann so aussehen: # /etc/fstab: static file system information. # # <file sys> <mount point> <type> <options> <dump> <pass>
# device during installation: /dev/nvme0n1p2 UUID=0dd9315b-f57a-41b2-ad39-520ec4274158 / ext4 defaults 0 1
# device during installation: /dev/nvme0n1p1 UUID=483B-7EA5 /boot/efi vfat rw 0 2
# device during installation: /dev/nvme1n1p1 UUID=b3a4c1d0-0710-4edc-bea3-dc84f8ed241f /home ext4 defaults 0 2
# device during installation: /dev/sda1 UUID=7ee633cb-2961-4473-8a88-2484e8780601 /datadisk2 ext4 noauto,user 0 2
# device during installation: /dev/nvme0n1p3 UUID=fbb099fa-8cfe-40ac-afbe-2fcb37b6bbe3 none swap sw 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 ro,user,noauto 0 0
Die beiden /backup und /backup2 wandern in die HDD: UUID=7ee633cb-2961-4473-8a88-2484e8780601 das root inkl. boot nach der SSD: UUID=59259677-fb46-4b39-a7cd-72a2e0687277 und /home in die SSD: UUID=6dc1df34-cca3-47dd-9be3-4626afcb5a94
Übersetzt lauten die UUIDs dann: ll /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 15 Apr 5 16:04 0dd9315b-f57a-41b2-ad39-520ec4274158 -> ../../nvme1n1p2 lrwxrwxrwx 1 root root 15 Apr 5 16:04 483B-7EA5 -> ../../nvme1n1p1 lrwxrwxrwx 1 root root 10 Apr 5 16:04 7ee633cb-2961-4473-8a88-2484e8780601 -> ../../sda1 lrwxrwxrwx 1 root root 10 Apr 5 15:59 9C41-74D5 -> ../../sdf1 lrwxrwxrwx 1 root root 15 Apr 5 16:04 b3a4c1d0-0710-4edc-bea3-dc84f8ed241f -> ../../nvme0n1p1 lrwxrwxrwx 1 root root 15 Apr 5 16:04 fbb099fa-8cfe-40ac-afbe-2fcb37b6bbe3 -> ../../nvme1n1p3
Umziehen wollte ich per rsync, erst auf externe Platte, dann von dieser auf den neuen Reczhner mit dem Befehl rsync --stats --progress --numeric-ids -axAhHSP /mnt/alt/ /mnt/neu
Danach sollte ich wohl auf der Kopie in der Datei /boot/grub2/grub.cfg die UUIDs tauschen, wohl am Besten mit suchen & ersetzen. also (/ alt) 59259677-fb46-4b39-a7cd-72a2e0687277 -> (/ neu) 0dd9315b-f57a-41b2-ad39-520ec4274158 Ist das korrekt so? Muss ich noch einen Datei anpassen?
Worin ich mich gar nicht auskenne ist die Sache mit dem UEFI. Wenn ich bisher ein System umgezogen habe, habe ich zuerst von einer DVD oder Stick gebootet, dann mount /dev/nvme1n1p2 /mnt mount --bind /dev /mnt/dev mount --bind /sys /mn/sys mount --bind /proc /mnt/proc chroot /mnt
und jetzt kommt die Frage, wohin zeigt grub2-install? In die EFI Partition /dev/nvme1n1p1, also grub2-install /dev/nvme1n1p1? grub2-mkconfig -o /boot/grub2/grub.cfg
Da in dem Neuen Rechner eine neuere, leistungsstärkere Nvidia-Karte steckt, muss ich diese # zypper se -si nvidia Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository ---+-------------------------------+---------+----------------------------- ---------+--------+------------------------ i+ | nvidia-computeG03 | package | 340.107-lp150.12.2 | x86_64 | nVidia Graphics Drivers i+ | nvidia-gfxG03-kmp-default | package | 340.107_k4.12.14_lp150.11-lp150.12.2 | x86_64 | nVidia Graphics Drivers i+ | nvidia-glG03 | package | 340.107-lp150.12.2 | x86_64 | nVidia Graphics Drivers i+ | nvidia-uvm-gfxG03-kmp-default | package | 340.107_k4.12.14_lp150.11-lp150.12.1 | x86_64 | nVidia Graphics Drivers i+ | x11-video-nvidiaG03 | package | 340.107-lp150.12.2 | x86_64 | nVidia Graphics Drivers
durch diese
# zypper se -si nvidia Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository ---+---------------------------+---------+--------------------------------- ---+--------+------------------------------- i+ | nvidia-computeG05 | package | 418.43-lp150.9.1 | x86_64 | TUXEDO Computers - 15.0 NVIDIA i+ | nvidia-gfxG05-kmp-default | package | 418.43_k4.12.14_lp150.11-lp150.9.1 | x86_64 | TUXEDO Computers - 15.0 NVIDIA i+ | nvidia-glG05 | package | 418.43-lp150.9.1 | x86_64 | TUXEDO Computers - 15.0 NVIDIA i+ | x11-video-nvidiaG05 | package | 418.43-lp150.9.1 | x86_64 | TUXEDO Computers - 15.0 NVIDIA
ersetzen. Mache ich wohl am Besten mit einem Yast in der Konsole, falls X nicht läuft, oder gibt es da auch einen zypper Befehl?
Frage ist dann noch, ob die neue Netzwerkkarte mit der alten Konfiguration läuft, oder ob ich da auf der Kopie auch noch eine datei editieren muss, vor dem Kopieren auf das Zielsystem?
Also viele Frage, vielleicht bekomme ich zielführende Antworten. Danke.
Gruß
Herbert Hallo,
das Meiste funktioniert nun. Doch muss ich aus historischen Gründen für eine ältere Anwendung meine MAC-Adresse maskieren. Auf dem alten Rechner ging das nach dem booten durch einen Eintrag in /etc/systemd/system/macspoof@.service. Händisch funktioniert es mit macchanger --mac=XX:XX:XX:XX:XX:XX eth0 ~ # systemctl status macspoof@eth0.service ● macspoof@eth0.service - macchanger on eth0 Loaded: loaded (/etc/systemd/system/macspoof@.service; disabled; vendor preset: disabled) Active: inactive (dead) Apr 21 23:26:43 wodan2.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Führe ich ein systemctl start macspoof@eth0.service aus, wird die MAC-Adresse gesetzt. Warum nicht beim Systemstart? Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Sonntag, 21. April 2019, 23:34:07 CEST schrieb Herbert Albert:
Händisch funktioniert es mit macchanger --mac=XX:XX:XX:XX:XX:XX eth0
~ # systemctl status macspoof@eth0.service ● macspoof@eth0.service - macchanger on eth0 Loaded: loaded (/etc/systemd/system/macspoof@.service; disabled; vendor preset: disabled) Active: inactive (dead)
Apr 21 23:26:43 wodan2.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument
Führe ich ein systemctl start macspoof@eth0.service aus, wird die MAC-Adresse gesetzt. Warum nicht beim Systemstart?
Gruß
Herbert sytemctl enable deinservice ?
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Montag, 22. April 2019, 10:07:09 CEST schrieb Hugo:
Am Sonntag, 21. April 2019, 23:34:07 CEST schrieb Herbert Albert:
Händisch funktioniert es mit macchanger --mac=XX:XX:XX:XX:XX:XX eth0
~ # systemctl status macspoof@eth0.service ● macspoof@eth0.service - macchanger on eth0
Loaded: loaded (/etc/systemd/system/macspoof@.service; disabled; vendor
preset: disabled)
Active: inactive (dead)
Apr 21 23:26:43 wodan2.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument
Führe ich ein systemctl start macspoof@eth0.service aus, wird die MAC-Adresse gesetzt. Warum nicht beim Systemstart?
Gruß
Herbert
sytemctl enable deinservice ? Hilft leider nicht.
nach der Eingabe von systemctl enable macspoof@eth0.service und einem Neustart erhalte ich auf das Kommando ~ # macchanger -s eth0 Current MAC: XX:XX:XX:XX:XX:XX (unknown) Permanent MAC: XX:XX:XX:XX:XX:XX (unknown), also noch die Original MAC Eine Abfrage ergibt: ~ # systemctl status macspoof@eth0.service ? macspoof@eth0.service - macchanger on eth0 Loaded: loaded (/etc/systemd/system/macspoof@.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Mon 2019-04-22 10:51:40 CEST; 3min 59s ago Main PID: 1062 (code=exited, status=1/FAILURE) Apr 22 10:51:40 NeuerRechnerName macchanger[1062]: [ERROR] Set device name: No such device Apr 22 10:51:40 NeuerRechnerName systemd[1]: macspoof@eth0.service: Main process exited, code=exited, status=1/FAILURE Apr 22 10:51:40 NeuerRechnerName systemd[1]: Failed to start macchanger on eth0. Apr 22 10:51:40 NeuerRechnerName systemd[1]: macspoof@eth0.service: Unit entered failed state. Apr 22 10:51:40 NeuerRechnerName systemd[1]: macspoof@eth0.service: Failed with result 'exit-code'. Apr 22 10:51:40 NeuerRechnerName systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Apr 22 10:51:57 NeuerRechnerName.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Apr 22 10:51:57 NeuerRechnerName.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Apr 22 10:51:57 NeuerRechnerName.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Apr 22 10:54:13 NeuerRechnerName.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Setze ich ~ # systemctl start macspoof@eth0.service erhalte ich ~ # macchanger -s eth0 Current MAC: YY:YY:YY:YY:YY:YY (Apple) Permanent MAC: XX:XX:XX:XX:XX:XX (unknown) also die gewünschte MAC Auch die Statusabfrage stimmt dann. ~ # systemctl status macspoof@eth0.service ? macspoof@eth0.service - macchanger on eth0 Loaded: loaded (/etc/systemd/system/macspoof@.service; enabled; vendor preset: disabled) Active: inactive (dead) since Mon 2019-04-22 11:04:42 CEST; 2min 55s ago Process: 4931 ExecStart=/usr/bin/macchanger --mac=YY:YY:YY:YY:YY:YY eth0 (code=exited, status=0/SUCCESS) Main PID: 4931 (code=exited, status=0/SUCCESS) Apr 22 11:04:42 NeuerRechnerName.fritz.box systemd[1]: Starting macchanger on eth0... Apr 22 11:04:42 NeuerRechnerName.fritz.box macchanger[4931]: Current MAC: XX:XX:XX:XX:XX:XX (unknown) Apr 22 11:04:42 NeuerRechnerName.fritz.box macchanger[4931]: Permanent MAC: XX:XX:XX:XX:XX:XX (unknown) Apr 22 11:04:42 NeuerRechnerName.fritz.box macchanger[4931]: New MAC: YY:YY:YY:YY:YY:YY (Apple) Apr 22 11:04:42 NeuerRechnerName.fritz.box systemd[1]: Started macchanger on eth0. Warum geht das nicht automatisch beim Start? Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Herbert, also ich denke enabled hat schon was gebracht. Am Montag, 22. April 2019, 11:09:48 CEST schrieb Herbert Albert:
Am Montag, 22. April 2019, 10:07:09 CEST schrieb Hugo:
Am Sonntag, 21. April 2019, 23:34:07 CEST schrieb Herbert Albert:
Händisch funktioniert es mit macchanger --mac=XX:XX:XX:XX:XX:XX eth0
~ # systemctl status macspoof@eth0.service ● macspoof@eth0.service - macchanger on eth0
Loaded: loaded (/etc/systemd/system/macspoof@.service; disabled; vendor Hier war disabled.
preset: disabled)
Active: inactive (dead)
Apr 21 23:26:43 wodan2.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument
Führe ich ein systemctl start macspoof@eth0.service aus, wird die MAC-Adresse gesetzt. Warum nicht beim Systemstart?
Gruß
Herbert
sytemctl enable deinservice ?
Hilft leider nicht.
nach der Eingabe von systemctl enable macspoof@eth0.service und einem Neustart erhalte ich auf das Kommando
~ # macchanger -s eth0 Current MAC: XX:XX:XX:XX:XX:XX (unknown) Permanent MAC: XX:XX:XX:XX:XX:XX (unknown),
also noch die Original MAC
Eine Abfrage ergibt: ~ # systemctl status macspoof@eth0.service ? macspoof@eth0.service - macchanger on eth0 Loaded: loaded (/etc/systemd/system/macspoof@.service; enabled; vendor preset: disabled) Hier ist jetzt enabled. Ist doch ein Fortschritt.
Active: failed (Result: exit-code) since Mon 2019-04-22 10:51:40 CEST; Da stimmt doch was nicht.
3min 59s ago Main PID: 1062 (code=exited, status=1/FAILURE)
Apr 22 10:51:40 NeuerRechnerName macchanger[1062]: [ERROR] Set device name: No such device Kann es sein, daß zu diesem Zeitpunkt eth0 unbekannt ist? Den service macspoof... habe ich gar nicht. Aber mit journalctl finde ich etwas wie ... NetworkManager[1258]: ... device (eth0): Activation: successful, device activated. Hast Du wohl auch. Passt das mit der Meldung von macspoof.. zusammen? Vielleicht ist es ja nur ein Zeitproblem?
Apr 22 10:51:40 NeuerRechnerName systemd[1]: macspoof@eth0.service: Main process exited, code=exited, status=1/FAILURE Apr 22 10:51:40 NeuerRechnerName systemd[1]: Failed to start macchanger on eth0. Apr 22 10:51:40 NeuerRechnerName systemd[1]: macspoof@eth0.service: Unit entered failed state. Apr 22 10:51:40 NeuerRechnerName systemd[1]: macspoof@eth0.service: Failed with result 'exit-code'. Apr 22 10:51:40 NeuerRechnerName systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Apr 22 10:51:57 NeuerRechnerName.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Apr 22 10:51:57 NeuerRechnerName.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Apr 22 10:51:57 NeuerRechnerName.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Apr 22 10:54:13 NeuerRechnerName.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument
Setze ich ~ # systemctl start macspoof@eth0.service erhalte ich ~ # macchanger -s eth0 Current MAC: YY:YY:YY:YY:YY:YY (Apple) Permanent MAC: XX:XX:XX:XX:XX:XX (unknown) also die gewünschte MAC
Auch die Statusabfrage stimmt dann. ~ # systemctl status macspoof@eth0.service ? macspoof@eth0.service - macchanger on eth0 Loaded: loaded (/etc/systemd/system/macspoof@.service; enabled; vendor preset: disabled) Active: inactive (dead) since Mon 2019-04-22 11:04:42 CEST; 2min 55s ago Process: 4931 ExecStart=/usr/bin/macchanger --mac=YY:YY:YY:YY:YY:YY eth0 (code=exited, status=0/SUCCESS) Main PID: 4931 (code=exited, status=0/SUCCESS)
Apr 22 11:04:42 NeuerRechnerName.fritz.box systemd[1]: Starting macchanger on eth0... Apr 22 11:04:42 NeuerRechnerName.fritz.box macchanger[4931]: Current MAC: XX:XX:XX:XX:XX:XX (unknown) Apr 22 11:04:42 NeuerRechnerName.fritz.box macchanger[4931]: Permanent MAC: XX:XX:XX:XX:XX:XX (unknown) Apr 22 11:04:42 NeuerRechnerName.fritz.box macchanger[4931]: New MAC: YY:YY:YY:YY:YY:YY (Apple) Apr 22 11:04:42 NeuerRechnerName.fritz.box systemd[1]: Started macchanger on eth0.
Warum geht das nicht automatisch beim Start? S.o. Zeitprobleme? macspoof später? Schöne Grüße und frohe Ostern. Hugo Mahr
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Hugo, Am Montag, 22. April 2019, 12:14:44 CEST schrieb Hugo:
Hallo Herbert, also ich denke enabled hat schon was gebracht.
kann ich nicht sagen, denn
Am Montag, 22. April 2019, 11:09:48 CEST schrieb Herbert Albert:
Am Montag, 22. April 2019, 10:07:09 CEST schrieb Hugo:
Am Sonntag, 21. April 2019, 23:34:07 CEST schrieb Herbert Albert:
Händisch funktioniert es mit macchanger --mac=XX:XX:XX:XX:XX:XX eth0
~ # systemctl status macspoof@eth0.service ● macspoof@eth0.service - macchanger on eth0
Loaded: loaded (/etc/systemd/system/macspoof@.service; disabled; vendor
Hier war disabled.
preset: disabled)
Active: inactive (dead)
Apr 21 23:26:43 wodan2.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument
Führe ich ein systemctl start macspoof@eth0.service aus, wird die MAC-Adresse gesetzt. Warum nicht beim Systemstart?
Gruß
Herbert
sytemctl enable deinservice ?
Hilft leider nicht.
nach der Eingabe von systemctl enable macspoof@eth0.service und einem Neustart erhalte ich auf das Kommando
~ # macchanger -s eth0 Current MAC: XX:XX:XX:XX:XX:XX (unknown) Permanent MAC: XX:XX:XX:XX:XX:XX (unknown),
also noch die Original MAC
Eine Abfrage ergibt: ~ # systemctl status macspoof@eth0.service ? macspoof@eth0.service - macchanger on eth0
Loaded: loaded (/etc/systemd/system/macspoof@.service; enabled; vendor
preset: disabled)
Hier ist jetzt enabled. Ist doch ein Fortschritt.
das hatte ich auch vor dem Befehl systemctl enable macspoof@eth0.service wenn ich per Hand ein systemctl start macspoof@eth0.service ausgeführt habe. Was ich aber will, ist das es automatisch beim Rechnerstart ausgeführt wird und das klappt nicht.
Active: failed (Result: exit-code) since Mon 2019-04-22 10:51:40 CEST;
Da stimmt doch was nicht.
3min 59s ago
Main PID: 1062 (code=exited, status=1/FAILURE)
Apr 22 10:51:40 NeuerRechnerName macchanger[1062]: [ERROR] Set device name: No such device
Kann es sein, daß zu diesem Zeitpunkt eth0 unbekannt ist? Den service macspoof... habe ich gar nicht. Aber mit journalctl finde ich etwas wie ... NetworkManager[1258]: ... device (eth0): Activation: successful, device activated. Hast Du wohl auch. Passt das mit der Meldung von macspoof.. zusammen? Vielleicht ist es ja nur ein Zeitproblem?
Meine Netzwerkverbindung läuft nicht mit dem NetworManager sondern mit den Wicked Dienst.
Apr 22 10:51:40 NeuerRechnerName systemd[1]: macspoof@eth0.service: Main process exited, code=exited, status=1/FAILURE Apr 22 10:51:40 NeuerRechnerName systemd[1]: Failed to start macchanger on eth0. Apr 22 10:51:40 NeuerRechnerName systemd[1]: macspoof@eth0.service: Unit entered failed state. Apr 22 10:51:40 NeuerRechnerName systemd[1]: macspoof@eth0.service: Failed with result 'exit-code'. Apr 22 10:51:40 NeuerRechnerName systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Apr 22 10:51:57 NeuerRechnerName.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Apr 22 10:51:57 NeuerRechnerName.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Apr 22 10:51:57 NeuerRechnerName.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument Apr 22 10:54:13 NeuerRechnerName.fritz.box systemd[1]: /etc/systemd/system/ macspoof@.service:8: Failed to add dependency on sys-subsystem-net-devices- %I.device, ignoring: Invalid argument
Setze ich ~ # systemctl start macspoof@eth0.service erhalte ich ~ # macchanger -s eth0 Current MAC: YY:YY:YY:YY:YY:YY (Apple) Permanent MAC: XX:XX:XX:XX:XX:XX (unknown) also die gewünschte MAC
Auch die Statusabfrage stimmt dann. ~ # systemctl status macspoof@eth0.service ? macspoof@eth0.service - macchanger on eth0
Loaded: loaded (/etc/systemd/system/macspoof@.service; enabled; vendor
preset: disabled)
Active: inactive (dead) since Mon 2019-04-22 11:04:42 CEST; 2min 55s ago
Process: 4931 ExecStart=/usr/bin/macchanger --mac=YY:YY:YY:YY:YY:YY eth0
(code=exited, status=0/SUCCESS)
Main PID: 4931 (code=exited, status=0/SUCCESS)
Apr 22 11:04:42 NeuerRechnerName.fritz.box systemd[1]: Starting macchanger on eth0... Apr 22 11:04:42 NeuerRechnerName.fritz.box macchanger[4931]: Current MAC: XX:XX:XX:XX:XX:XX (unknown) Apr 22 11:04:42 NeuerRechnerName.fritz.box macchanger[4931]: Permanent MAC: XX:XX:XX:XX:XX:XX (unknown) Apr 22 11:04:42 NeuerRechnerName.fritz.box macchanger[4931]: New MAC: YY:YY:YY:YY:YY:YY (Apple) Apr 22 11:04:42 NeuerRechnerName.fritz.box systemd[1]: Started macchanger on eth0.
Warum geht das nicht automatisch beim Start?
S.o. Zeitprobleme? macspoof später?
Darauf tippe ich auch, nur wo stelle ich die Reihenfolge um?
Schöne Grüße und frohe Ostern. Hugo Mahr
Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 22.04.19 um 18:45 schrieb Herbert Albert:
[...] wenn ich per Hand ein
systemctl start macspoof@eth0.service
ausgeführt habe. Was ich aber will, ist das es automatisch beim Rechnerstart ausgeführt wird und das klappt nicht.
[...] Herbert
Bzgl. der Startreihenfolge empfehle ich dir mal Folgendes anschauen: $ man systemd.units und dort speziell: Requires= Requisite= Wants= BindsTo= und ggfls. mehr als das. Viel Erfolg Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 22.04.2019 um 19:04 schrieb Martin Deppe:
Am 22.04.19 um 18:45 schrieb Herbert Albert:
[...] wenn ich per Hand ein
systemctl start macspoof@eth0.service
ausgeführt habe. Was ich aber will, ist das es automatisch beim Rechnerstart ausgeführt wird und das klappt nicht.
[...] Herbert
Bzgl. der Startreihenfolge empfehle ich dir mal Folgendes anschauen: $ man systemd.units und dort speziell: Requires= Requisite= Wants= BindsTo= und ggfls. mehr als das.
'systemctl edit macspoof@eth0' sollte dann dein Freund sein Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Montag, 22. April 2019, 19:07:52 CEST schrieb Manfred Kreisl:
Am 22.04.2019 um 19:04 schrieb Martin Deppe:
Am 22.04.19 um 18:45 schrieb Herbert Albert:
[...] wenn ich per Hand ein
systemctl start macspoof@eth0.service
ausgeführt habe. Was ich aber will, ist das es automatisch beim Rechnerstart ausgeführt wird und das klappt nicht.
[...] Herbert
Bzgl. der Startreihenfolge empfehle ich dir mal Folgendes anschauen: $ man systemd.units
und dort speziell: Requires= Requisite= Wants= BindsTo=
und ggfls. mehr als das.
'systemctl edit macspoof@eth0' sollte dann dein Freund sein
Manfred Hallo Martin,
wenn ich systemctl edit macspoof@eth0 ausführe, lande ich in dem Editor nano mit einer leeren Datei /etc/systemd/system/macspoof@eth0.service.d/.#override.conf92ea33d70af620ce Auf dem alten Rechner hat es nur mit der Datei /etc/systemd/system/macspoof@.service die wiederum ein link auf lrwxrwxrwx 1 root root 37 Apr 22 10:37 /etc/systemd/system/multi- user.target.wants/macspoof@eth0.service -> /etc/systemd/system/ macspoof@.service war. Inhalt: [Unit] Description=macchanger on %I Before=NetworkManager.service After=sys-subsystem-net-devices-%I.device [Service] ExecStart=/usr/bin/macchanger --mac=YY:YY:YY:YY:YY:YY %I Type=oneshot [Install] WantedBy=multi-user.target Der Aufruf der Manpage führt zu: ~ # man systemd.units No manual entry for systemd.units Bei Tante Google habe ich das hier https://www.linuxuprising.com/2018/05/how-to-permanently-change-mac-address.... gefunden, aber ob die Einträge passen? Vielleicht hast Du Vorschläge was ich in die /etc/systemd/system/ macspoof@.service eintragen sollte. Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Montag, 22. April 2019, 19:42:38 CEST schrieb Herbert Albert:
Am Montag, 22. April 2019, 19:07:52 CEST schrieb Manfred Kreisl:
Am 22.04.2019 um 19:04 schrieb Martin Deppe:
Am 22.04.19 um 18:45 schrieb Herbert Albert:
[...] wenn ich per Hand ein
systemctl start macspoof@eth0.service
ausgeführt habe. Was ich aber will, ist das es automatisch beim Rechnerstart ausgeführt wird und das klappt nicht.
[...] Herbert
Bzgl. der Startreihenfolge empfehle ich dir mal Folgendes anschauen: $ man systemd.units
und dort speziell: Requires= Requisite= Wants= BindsTo=
und ggfls. mehr als das.
'systemctl edit macspoof@eth0' sollte dann dein Freund sein
Manfred
Hallo Martin,
wenn ich systemctl edit macspoof@eth0 ausführe, lande ich in dem Editor nano mit einer leeren Datei /etc/systemd/system/macspoof@eth0.service.d/.#override.conf92ea33d70af620ce
Auf dem alten Rechner hat es nur mit der Datei /etc/systemd/system/macspoof@.service die wiederum ein link auf lrwxrwxrwx 1 root root 37 Apr 22 10:37 /etc/systemd/system/multi- user.target.wants/macspoof@eth0.service -> /etc/systemd/system/ macspoof@.service war.
Inhalt: [Unit] Description=macchanger on %I Before=NetworkManager.service After=sys-subsystem-net-devices-%I.device
[Service] ExecStart=/usr/bin/macchanger --mac=YY:YY:YY:YY:YY:YY %I Type=oneshot
[Install] WantedBy=multi-user.target
Der Aufruf der Manpage führt zu:
~ # man systemd.units No manual entry for systemd.units
Bei Tante Google habe ich das hier https://www.linuxuprising.com/2018/05/how-to-permanently-change-mac-address. html gefunden, aber ob die Einträge passen?
Vielleicht hast Du Vorschläge was ich in die /etc/systemd/system/ macspoof@.service eintragen sollte.
Gruß
Herbert kann es vielleicht daran liegen, dass der 11 Jahre alte Rechner langsamer bootet und der neue von der SSD viel schneller. Laufen da Bootprozesse evtl. parallel ab? Kenn mich da leider gar nicht aus.
Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 22.04.2019 um 19:46 schrieb Herbert Albert:
Am Montag, 22. April 2019, 19:42:38 CEST schrieb Herbert Albert:
Am Montag, 22. April 2019, 19:07:52 CEST schrieb Manfred Kreisl:
Am 22.04.2019 um 19:04 schrieb Martin Deppe:
Am 22.04.19 um 18:45 schrieb Herbert Albert:
[...] wenn ich per Hand ein
systemctl start macspoof@eth0.service
ausgeführt habe. Was ich aber will, ist das es automatisch beim Rechnerstart ausgeführt wird und das klappt nicht.
[...] Herbert
Bzgl. der Startreihenfolge empfehle ich dir mal Folgendes anschauen: $ man systemd.units
und dort speziell: Requires= Requisite= Wants= BindsTo=
und ggfls. mehr als das.
'systemctl edit macspoof@eth0' sollte dann dein Freund sein
Manfred
Hallo Martin,
wenn ich systemctl edit macspoof@eth0 ausführe, lande ich in dem Editor nano mit einer leeren Datei /etc/systemd/system/macspoof@eth0.service.d/.#override.conf92ea33d70af620ce
Auf dem alten Rechner hat es nur mit der Datei /etc/systemd/system/macspoof@.service die wiederum ein link auf lrwxrwxrwx 1 root root 37 Apr 22 10:37 /etc/systemd/system/multi- user.target.wants/macspoof@eth0.service -> /etc/systemd/system/ macspoof@.service war.
Inhalt: [Unit] Description=macchanger on %I Before=NetworkManager.service After=sys-subsystem-net-devices-%I.device
[Service] ExecStart=/usr/bin/macchanger --mac=YY:YY:YY:YY:YY:YY %I Type=oneshot
[Install] WantedBy=multi-user.target
Der Aufruf der Manpage führt zu:
~ # man systemd.units No manual entry for systemd.units
Bei Tante Google habe ich das hier https://www.linuxuprising.com/2018/05/how-to-permanently-change-mac-address. html gefunden, aber ob die Einträge passen?
Vielleicht hast Du Vorschläge was ich in die /etc/systemd/system/ macspoof@.service eintragen sollte.
Gruß
Herbert kann es vielleicht daran liegen, dass der 11 Jahre alte Rechner langsamer bootet und der neue von der SSD viel schneller. Laufen da Bootprozesse evtl. parallel ab? Kenn mich da leider gar nicht aus. Klar, alle Dienste, die nicht voneinander abhängig sind, werden parallel gestartet. Und ja, eine SSD beeinflusst das Bootverhalten durchaus.
Du musst an dem After= Eintrag herumfummeln Trage dort etwas ein, was garantiert spät(er) gestartet wird, vll hilft After=network.target ja schon Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Montag, 22. April 2019, 19:57:17 CEST schrieb Manfred Kreisl:
Am 22.04.2019 um 19:46 schrieb Herbert Albert:
Am Montag, 22. April 2019, 19:42:38 CEST schrieb Herbert Albert:
Am Montag, 22. April 2019, 19:07:52 CEST schrieb Manfred Kreisl:
Am 22.04.2019 um 19:04 schrieb Martin Deppe:
Am 22.04.19 um 18:45 schrieb Herbert Albert:
[...] wenn ich per Hand ein
systemctl start macspoof@eth0.service
ausgeführt habe. Was ich aber will, ist das es automatisch beim Rechnerstart ausgeführt wird und das klappt nicht.
[...] Herbert
Bzgl. der Startreihenfolge empfehle ich dir mal Folgendes anschauen: $ man systemd.units
und dort speziell: Requires= Requisite= Wants= BindsTo=
und ggfls. mehr als das.
'systemctl edit macspoof@eth0' sollte dann dein Freund sein
Manfred
Hallo Martin,
wenn ich systemctl edit macspoof@eth0 ausführe, lande ich in dem Editor nano mit einer leeren Datei /etc/systemd/system/macspoof@eth0.service.d/.#override.conf92ea33d70af620 ce
Auf dem alten Rechner hat es nur mit der Datei /etc/systemd/system/macspoof@.service die wiederum ein link auf lrwxrwxrwx 1 root root 37 Apr 22 10:37 /etc/systemd/system/multi- user.target.wants/macspoof@eth0.service -> /etc/systemd/system/ macspoof@.service war.
Inhalt: [Unit] Description=macchanger on %I Before=NetworkManager.service After=sys-subsystem-net-devices-%I.device
[Service] ExecStart=/usr/bin/macchanger --mac=YY:YY:YY:YY:YY:YY %I Type=oneshot
[Install] WantedBy=multi-user.target
Der Aufruf der Manpage führt zu:
~ # man systemd.units No manual entry for systemd.units
Bei Tante Google habe ich das hier https://www.linuxuprising.com/2018/05/how-to-permanently-change-mac-addre ss. html gefunden, aber ob die Einträge passen?
Vielleicht hast Du Vorschläge was ich in die /etc/systemd/system/ macspoof@.service eintragen sollte.
Gruß
Herbert
kann es vielleicht daran liegen, dass der 11 Jahre alte Rechner langsamer bootet und der neue von der SSD viel schneller. Laufen da Bootprozesse evtl. parallel ab? Kenn mich da leider gar nicht aus.
Klar, alle Dienste, die nicht voneinander abhängig sind, werden parallel gestartet. Und ja, eine SSD beeinflusst das Bootverhalten durchaus.
Du musst an dem After= Eintrag herumfummeln Trage dort etwas ein, was garantiert spät(er) gestartet wird, vll hilft After=network.target ja schon
Manfred Hallo Manfred,
der Tipp war gut. Anstelle "After=sys-subsystem-net-devices-%I.device" steht nun "After=network.target" ~ # macchanger -s eth0 Current MAC: YY:YY:YY:YY:YY:YY (Apple) Permanent MAC: XX:XX:XX:XX:XX:XX (unknown) Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 22.04.2019 um 20:11 schrieb Herbert Albert: [...]
kann es vielleicht daran liegen, dass der 11 Jahre alte Rechner langsamer bootet und der neue von der SSD viel schneller. Laufen da Bootprozesse evtl. parallel ab? Kenn mich da leider gar nicht aus.
Klar, alle Dienste, die nicht voneinander abhängig sind, werden parallel gestartet. Und ja, eine SSD beeinflusst das Bootverhalten durchaus.
Du musst an dem After= Eintrag herumfummeln Trage dort etwas ein, was garantiert spät(er) gestartet wird, vll hilft After=network.target ja schon
Manfred Hallo Manfred,
der Tipp war gut. Anstelle "After=sys-subsystem-net-devices-%I.device" steht nun "After=network.target"
~ # macchanger -s eth0 Current MAC: YY:YY:YY:YY:YY:YY (Apple) Permanent MAC: XX:XX:XX:XX:XX:XX (unknown)
Na prima :) Hast Du das in der orginalen Datei geändert oder eine Override Datei angelegt. In der orginalen Datei zu ändern ist nicht gerade ratsam, da die Anderungen beim Paket-Update wieder weg sind. Gab da mal nen interessanten Thread von Jürgen, hab ihn mal hier erneut gepostet, kann ja nicht schaden ----------------------------------------------------------------------------------------------- Re: systemd / NFS-mounts vor APACHE (gelöst) Hallo allerseits, so nun habe ich's gelöst. Dank an alle Schreiber. Es geht also so: 1) in /etc/fstab die Mountpoints eintragen HOST:/pfad/zu/etc/ssh /etc/ssh nfs defaults 0 0 .... Hinweis: man sollte wohl nicht das /etc/ssh-Verzeichnis des Hosts per NFS exportieren, sondern ein ein für den Gast eigenes spezielles. ACHTUNG: bind-Mounts (wie ursprünglich von mir angedacht) scheinen nicht zu funktionieren. Die Dienste starten dann nicht. 2) ein "systemd-override" für den Dienst definieren, am einfachsten mit systemctl edit sshd das startet $EDITOR und dann fügt man folgendes ein: [Unit] RequiresMountsFor=/etc/ssh Man kann hier auch mehrere Mount-Points bei RequiresMountsFor angeben (durch Leerzeichen getrennt) Die "override-Datei" landet dann im Verzeichnis /etc/systemd/system/sshd.service.d/ (das Verzeichnis wird durch "systemctl edit sshd" angelegt) ACHTUNG die Zeile [Unit] nicht vergessen!!!!! Leider steht das in der SuSE Doku https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref... nicht so eindeutig drin: "Make sure it only contains the line with the value that you want to modify. " Meine Bitte an die Maintainer der Doku (falls die hier mitlesen), bitte präzisiert das, hat mich jetzt echt mehrere Stunden gekostet..... Das ganze habe ich nun für sshd, apache und mysql gemacht und funktioniert. So long & Bye Jürgen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Montag, 22. April 2019, 21:48:51 CEST schrieb Manfred Kreisl:
Am 22.04.2019 um 20:11 schrieb Herbert Albert: [...]
kann es vielleicht daran liegen, dass der 11 Jahre alte Rechner langsamer bootet und der neue von der SSD viel schneller. Laufen da Bootprozesse evtl. parallel ab? Kenn mich da leider gar nicht aus.
Klar, alle Dienste, die nicht voneinander abhängig sind, werden parallel gestartet. Und ja, eine SSD beeinflusst das Bootverhalten durchaus.
Du musst an dem After= Eintrag herumfummeln Trage dort etwas ein, was garantiert spät(er) gestartet wird, vll hilft After=network.target ja schon
Manfred
Hallo Manfred,
der Tipp war gut. Anstelle "After=sys-subsystem-net-devices-%I.device" steht nun "After=network.target"
~ # macchanger -s eth0 Current MAC: YY:YY:YY:YY:YY:YY (Apple) Permanent MAC: XX:XX:XX:XX:XX:XX (unknown)
Na prima :)
Hast Du das in der orginalen Datei geändert oder eine Override Datei angelegt.
In der orginalen Datei zu ändern ist nicht gerade ratsam, da die Anderungen beim Paket-Update wieder weg sind.
Gab da mal nen interessanten Thread von Jürgen, hab ihn mal hier erneut gepostet, kann ja nicht schaden
---------------------------------------------------------------------------- ------------------- Re: systemd / NFS-mounts vor APACHE (gelöst)
Hallo allerseits,
so nun habe ich's gelöst. Dank an alle Schreiber.
Es geht also so:
1) in /etc/fstab die Mountpoints eintragen
HOST:/pfad/zu/etc/ssh /etc/ssh nfs defaults 0 0 ....
Hinweis: man sollte wohl nicht das /etc/ssh-Verzeichnis des Hosts per NFS exportieren, sondern ein ein für den Gast eigenes spezielles.
ACHTUNG: bind-Mounts (wie ursprünglich von mir angedacht) scheinen nicht zu funktionieren. Die Dienste starten dann nicht.
2) ein "systemd-override" für den Dienst definieren, am einfachsten mit
systemctl edit sshd
das startet $EDITOR und dann fügt man folgendes ein:
[Unit] RequiresMountsFor=/etc/ssh
Man kann hier auch mehrere Mount-Points bei RequiresMountsFor angeben (durch Leerzeichen getrennt)
Die "override-Datei" landet dann im Verzeichnis /etc/systemd/system/sshd.service.d/ (das Verzeichnis wird durch "systemctl edit sshd" angelegt)
ACHTUNG die Zeile [Unit] nicht vergessen!!!!!
Leider steht das in der SuSE Doku
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref erence/cha.systemd.html#sec.boot.systemd.custom.drop-in nicht so eindeutig drin: "Make sure it only contains the line with the value that you want to modify. " Meine Bitte an die Maintainer der Doku (falls die hier mitlesen), bitte präzisiert das, hat mich jetzt echt mehrere Stunden gekostet.....
Das ganze habe ich nun für sshd, apache und mysql gemacht und funktioniert.
So long & Bye Jürgen Hallo Manfred,
Sachen gibt's, von denen habe ich noch nie was gehört. Ich habe es in der Original Datei /etc/systemd/system/macspoof@.service geändert. Bei dem Versuch mit dem edit ist auch eine leere Datei /etc/systemd/system/macspoof@eth0.service.d/override.conf angelegt worden. In der kann ich den gleichen Inhalt des Originals eintragen, doch wo muss die dann hin? Oder steht die schon am richtigen Ort? Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 22.04.2019 um 22:07 schrieb Herbert Albert:
Am Montag, 22. April 2019, 21:48:51 CEST schrieb Manfred Kreisl:
Am 22.04.2019 um 20:11 schrieb Herbert Albert: [...]
kann es vielleicht daran liegen, dass der 11 Jahre alte Rechner langsamer bootet und der neue von der SSD viel schneller. Laufen da Bootprozesse evtl. parallel ab? Kenn mich da leider gar nicht aus.
Klar, alle Dienste, die nicht voneinander abhängig sind, werden parallel gestartet. Und ja, eine SSD beeinflusst das Bootverhalten durchaus.
Du musst an dem After= Eintrag herumfummeln Trage dort etwas ein, was garantiert spät(er) gestartet wird, vll hilft After=network.target ja schon
Manfred
Hallo Manfred,
der Tipp war gut. Anstelle "After=sys-subsystem-net-devices-%I.device" steht nun "After=network.target"
~ # macchanger -s eth0 Current MAC: YY:YY:YY:YY:YY:YY (Apple) Permanent MAC: XX:XX:XX:XX:XX:XX (unknown)
Na prima :)
Hast Du das in der orginalen Datei geändert oder eine Override Datei angelegt.
In der orginalen Datei zu ändern ist nicht gerade ratsam, da die Anderungen beim Paket-Update wieder weg sind.
Gab da mal nen interessanten Thread von Jürgen, hab ihn mal hier erneut gepostet, kann ja nicht schaden
---------------------------------------------------------------------------- ------------------- Re: systemd / NFS-mounts vor APACHE (gelöst)
Hallo allerseits,
so nun habe ich's gelöst. Dank an alle Schreiber.
Es geht also so:
1) in /etc/fstab die Mountpoints eintragen
HOST:/pfad/zu/etc/ssh /etc/ssh nfs defaults 0 0 ....
Hinweis: man sollte wohl nicht das /etc/ssh-Verzeichnis des Hosts per NFS exportieren, sondern ein ein für den Gast eigenes spezielles.
ACHTUNG: bind-Mounts (wie ursprünglich von mir angedacht) scheinen nicht zu funktionieren. Die Dienste starten dann nicht.
2) ein "systemd-override" für den Dienst definieren, am einfachsten mit
systemctl edit sshd
das startet $EDITOR und dann fügt man folgendes ein:
[Unit] RequiresMountsFor=/etc/ssh
Man kann hier auch mehrere Mount-Points bei RequiresMountsFor angeben (durch Leerzeichen getrennt)
Die "override-Datei" landet dann im Verzeichnis /etc/systemd/system/sshd.service.d/ (das Verzeichnis wird durch "systemctl edit sshd" angelegt)
ACHTUNG die Zeile [Unit] nicht vergessen!!!!!
Leider steht das in der SuSE Doku
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref erence/cha.systemd.html#sec.boot.systemd.custom.drop-in nicht so eindeutig drin: "Make sure it only contains the line with the value that you want to modify. " Meine Bitte an die Maintainer der Doku (falls die hier mitlesen), bitte präzisiert das, hat mich jetzt echt mehrere Stunden gekostet.....
Das ganze habe ich nun für sshd, apache und mysql gemacht und funktioniert.
So long & Bye Jürgen Hallo Manfred,
Sachen gibt's, von denen habe ich noch nie was gehört.
Ging mir ebenso
Ich habe es in der Original Datei /etc/systemd/system/macspoof@.service geändert.
Bei dem Versuch mit dem edit ist auch eine leere Datei /etc/systemd/system/macspoof@eth0.service.d/override.conf angelegt worden. In der kann ich den gleichen Inhalt des Originals eintragen, doch wo muss die dann hin? Oder steht die schon am richtigen Ort?
Der Ort ist schon der Richtige Ich vermute mal, [Unit] After=network.target sollte reichen. Wie der Name schon sagt, werden vorhandene Einträge überschrieben oder halt ergänzt Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Montag, 22. April 2019, 22:16:00 CEST schrieb Manfred Kreisl:
Am 22.04.2019 um 22:07 schrieb Herbert Albert:
Am Montag, 22. April 2019, 21:48:51 CEST schrieb Manfred Kreisl:
Am 22.04.2019 um 20:11 schrieb Herbert Albert: [...]
kann es vielleicht daran liegen, dass der 11 Jahre alte Rechner langsamer bootet und der neue von der SSD viel schneller. Laufen da Bootprozesse evtl. parallel ab? Kenn mich da leider gar nicht aus.
Klar, alle Dienste, die nicht voneinander abhängig sind, werden parallel gestartet. Und ja, eine SSD beeinflusst das Bootverhalten durchaus.
Du musst an dem After= Eintrag herumfummeln Trage dort etwas ein, was garantiert spät(er) gestartet wird, vll hilft After=network.target ja schon
Manfred
Hallo Manfred,
der Tipp war gut. Anstelle "After=sys-subsystem-net-devices-%I.device" steht nun "After=network.target"
~ # macchanger -s eth0 Current MAC: YY:YY:YY:YY:YY:YY (Apple) Permanent MAC: XX:XX:XX:XX:XX:XX (unknown)
Na prima :)
Hast Du das in der orginalen Datei geändert oder eine Override Datei angelegt.
In der orginalen Datei zu ändern ist nicht gerade ratsam, da die Anderungen beim Paket-Update wieder weg sind.
Gab da mal nen interessanten Thread von Jürgen, hab ihn mal hier erneut gepostet, kann ja nicht schaden
------------------------------------------------------------------------- --- ------------------- Re: systemd / NFS-mounts vor APACHE (gelöst)
Hallo allerseits,
so nun habe ich's gelöst. Dank an alle Schreiber.
Es geht also so:
1) in /etc/fstab die Mountpoints eintragen
HOST:/pfad/zu/etc/ssh /etc/ssh
nfs defaults 0 0
....
Hinweis: man sollte wohl nicht das /etc/ssh-Verzeichnis des Hosts per
NFS exportieren, sondern ein ein für den
Gast eigenes spezielles.
ACHTUNG: bind-Mounts (wie ursprünglich von mir angedacht) scheinen
nicht zu funktionieren. Die Dienste starten dann nicht.
2) ein "systemd-override" für den Dienst definieren, am einfachsten mit
systemctl edit sshd
das startet $EDITOR und dann fügt man folgendes ein: [Unit] RequiresMountsFor=/etc/ssh
Man kann hier auch mehrere Mount-Points bei RequiresMountsFor
angeben (durch Leerzeichen getrennt)
Die "override-Datei" landet dann im Verzeichnis
/etc/systemd/system/sshd.service.d/
(das Verzeichnis wird durch "systemctl edit sshd" angelegt)
ACHTUNG die Zeile
[Unit]
nicht vergessen!!!!!
Leider steht das in der SuSE Doku
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse. ref erence/cha.systemd.html#sec.boot.systemd.custom.drop-in nicht so eindeutig>> drin: "Make sure it only contains the line with the value that you want to
modify. "
Meine Bitte an die Maintainer der Doku (falls die hier mitlesen),
bitte präzisiert das, hat mich jetzt echt mehrere Stunden gekostet.....
Das ganze habe ich nun für sshd, apache und mysql gemacht und funktioniert.
So long & Bye Jürgen
Hallo Manfred,
Sachen gibt's, von denen habe ich noch nie was gehört.
Ging mir ebenso
Ich habe es in der Original Datei /etc/systemd/system/macspoof@.service geändert.
Bei dem Versuch mit dem edit ist auch eine leere Datei /etc/systemd/system/macspoof@eth0.service.d/override.conf angelegt worden. In der kann ich den gleichen Inhalt des Originals eintragen, doch wo muss die dann hin? Oder steht die schon am richtigen Ort?
Der Ort ist schon der Richtige
Ich vermute mal,
[Unit] After=network.target
sollte reichen.
Wie der Name schon sagt, werden vorhandene Einträge überschrieben oder halt ergänzt
Manfred hab nun das gleiche Problem mit der Firewall. In Yast Diensteverwaltung steht On Boot, aber Inaktiv. Wenn ich ihn aktiviere ist er beim nächsten reboot wieder deaktiviert. So einen Stress hatte ich beim alten Rechner nicht. Bestimmte Sachen, wie KDE-Connect scheinen nur mit aktiver Firewall zu gehen.
Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo >Herbert, Am Mittwoch, 24. April 2019, 20:47:18 CEST schrieb Herbert Albert:>
hab nun das gleiche Problem mit der Firewall. In Yast Diensteverwaltung steht On Boot, aber Inaktiv. Wenn ich ihn aktiviere ist er beim nächsten reboot wieder deaktiviert. So einen Stress hatte ich beim alten Rechner nicht. Bestimmte Sachen, wie KDE-Connect scheinen nur mit aktiver Firewall zu gehen.
Wie sieht den journalctl info aus (option -r) ? Bei mir: # journalctl -r | grep firewall | head -20 Apr 25 18:18:21 ..,. kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 25 18:03:57 ..,..... systemd[1]: Started SuSEfirewall2 phase 2. Apr 25 18:03:57 ..,..... SuSEfirewall2[1254]: Firewall rules successfully set Apr 25 18:03:56 ..,..... SuSEfirewall2[1254]: Setting up rules from /etc/ sysconfig/SuSEfirewall2 ... Apr 25 18:03:55 ..,..... systemd[1]: Starting SuSEfirewall2 phase 2... Apr 25 18:03:54 ..,..... systemd[1]: Started SuSEfirewall2 phase 1. Apr 25 18:03:54 ..,..... SuSEfirewall2[943]: Firewall rules set to CLOSE. Apr 25 18:03:43 ..,..... systemd[1]: Starting SuSEfirewall2 phase 1... Apr 25 18:02:48 ..,. systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 25 18:02:45 ..,. systemd[1]: Stopping firewalld - dynamic firewall daemon... für mich sieht das so aus: Aktiv ist SuSEfirewall2 ohne systemd ? firewalld startet, wird aber angehalten. und yast2 bietet Konfiguration von firewalld an. Das ist seltsam. erklärt aber vielleicht warum Deine Änderung (die woln für firewalld ist nicht geht. Gruß Hugo Mahr -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 25. April 2019, 18:56:15 CEST schrieb Hugo:
Hallo >Herbert, Am Mittwoch, 24. April 2019, 20:47:18 CEST schrieb Herbert Albert:>
hab nun das gleiche Problem mit der Firewall. In Yast Diensteverwaltung steht On Boot, aber Inaktiv. Wenn ich ihn aktiviere ist er beim nächsten reboot wieder deaktiviert. So einen Stress hatte ich beim alten Rechner nicht. Bestimmte Sachen, wie KDE-Connect scheinen nur mit aktiver Firewall zu gehen.
Wie sieht den journalctl info aus (option -r) ? Bei mir: # journalctl -r | grep firewall | head -20 Apr 25 18:18:21 ..,. kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 25 18:03:57 ..,..... systemd[1]: Started SuSEfirewall2 phase 2. Apr 25 18:03:57 ..,..... SuSEfirewall2[1254]: Firewall rules successfully set Apr 25 18:03:56 ..,..... SuSEfirewall2[1254]: Setting up rules from /etc/ sysconfig/SuSEfirewall2 ... Apr 25 18:03:55 ..,..... systemd[1]: Starting SuSEfirewall2 phase 2... Apr 25 18:03:54 ..,..... systemd[1]: Started SuSEfirewall2 phase 1. Apr 25 18:03:54 ..,..... SuSEfirewall2[943]: Firewall rules set to CLOSE. Apr 25 18:03:43 ..,..... systemd[1]: Starting SuSEfirewall2 phase 1... Apr 25 18:02:48 ..,. systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 25 18:02:45 ..,. systemd[1]: Stopping firewalld - dynamic firewall daemon...
für mich sieht das so aus: Aktiv ist SuSEfirewall2 ohne systemd ? firewalld startet, wird aber angehalten.
und yast2 bietet Konfiguration von firewalld an.
Das ist seltsam. erklärt aber vielleicht warum Deine Änderung (die woln für firewalld ist nicht geht.
Gruß Hugo Mahr hinzu kommt nun auch noch, dass meine Samba-Freigaben (home-Verzeichnis der User) in den VirtualBox-Gastsytemen aus Redmond nicht mehr per \\Rechnername \user funktionieren. Auch das hat wohl mit der Firewall zu tun, da ich alles von /etc/samba umgezogen habe und die passwd neu gesetzt habe.
Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 25. April 2019, 18:56:15 CEST schrieb Hugo:
Hallo >Herbert, Am Mittwoch, 24. April 2019, 20:47:18 CEST schrieb Herbert Albert:>
hab nun das gleiche Problem mit der Firewall. In Yast Diensteverwaltung steht On Boot, aber Inaktiv. Wenn ich ihn aktiviere ist er beim nächsten reboot wieder deaktiviert. So einen Stress hatte ich beim alten Rechner nicht. Bestimmte Sachen, wie KDE-Connect scheinen nur mit aktiver Firewall zu gehen.
Wie sieht den journalctl info aus (option -r) ? Bei mir: # journalctl -r | grep firewall | head -20 Apr 25 18:18:21 ..,. kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 25 18:03:57 ..,..... systemd[1]: Started SuSEfirewall2 phase 2. Apr 25 18:03:57 ..,..... SuSEfirewall2[1254]: Firewall rules successfully set Apr 25 18:03:56 ..,..... SuSEfirewall2[1254]: Setting up rules from /etc/ sysconfig/SuSEfirewall2 ... Apr 25 18:03:55 ..,..... systemd[1]: Starting SuSEfirewall2 phase 2... Apr 25 18:03:54 ..,..... systemd[1]: Started SuSEfirewall2 phase 1. Apr 25 18:03:54 ..,..... SuSEfirewall2[943]: Firewall rules set to CLOSE. Apr 25 18:03:43 ..,..... systemd[1]: Starting SuSEfirewall2 phase 1... Apr 25 18:02:48 ..,. systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 25 18:02:45 ..,. systemd[1]: Stopping firewalld - dynamic firewall daemon...
für mich sieht das so aus: Aktiv ist SuSEfirewall2 ohne systemd ? firewalld startet, wird aber angehalten.
und yast2 bietet Konfiguration von firewalld an.
Das ist seltsam. erklärt aber vielleicht warum Deine Änderung (die woln für firewalld ist nicht geht.
Gruß Hugo Mahr Hallo Hugo,
wirst Du daraus schlau? NeuerRechner:~ # journalctl -r | grep firewall | head -20 Apr 25 19:54:21 NeuerRechner systemd[1]: Started SuSEfirewall2 phase 2. Apr 25 19:54:21 NeuerRechner SuSEfirewall2[1370]: Firewall rules successfully set Apr 25 19:54:20 NeuerRechner SuSEfirewall2[1370]: using default zone 'ext' for interface eth0 Apr 25 19:54:20 NeuerRechner SuSEfirewall2[1370]: Setting up rules from /etc/ sysconfig/SuSEfirewall2 ... Apr 25 19:54:20 NeuerRechner systemd[1]: Starting SuSEfirewall2 phase 2... Apr 25 19:54:17 NeuerRechner systemd[1]: Started SuSEfirewall2 phase 1. Apr 25 19:54:17 NeuerRechner SuSEfirewall2[771]: Firewall rules set to CLOSE. Apr 25 19:54:16 NeuerRechner systemd[1]: Starting SuSEfirewall2 phase 1... Apr 24 22:19:30 NeuerRechner.fritz.box systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 24 22:19:28 NeuerRechner.fritz.box systemd[1]: Stopping firewalld - dynamic firewall daemon... Apr 24 22:04:43 NeuerRechner.fritz.box kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 24 22:04:41 NeuerRechner.fritz.box systemd[1]: Started firewalld - dynamic firewall daemon. Apr 24 22:04:41 NeuerRechner.fritz.box systemd[1]: Starting firewalld - dynamic firewall daemon... Apr 24 22:04:41 NeuerRechner.fritz.box systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 24 22:04:36 NeuerRechner.fritz.box systemd[1]: Stopping firewalld - dynamic firewall daemon... Apr 24 21:10:57 NeuerRechner.fritz.box kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 24 21:10:29 NeuerRechner.fritz.box systemd[1]: Started firewalld - dynamic firewall daemon. Apr 24 21:10:29 NeuerRechner.fritz.box systemd[1]: Starting firewalld - dynamic firewall daemon... Apr 24 21:09:23 NeuerRechner.fritz.box systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 24 21:09:19 NeuerRechner.fritz.box systemd[1]: Stopping firewalld - dynamic firewall daemon... NeuerRechner:~ # Gruß Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 25. April 2019, 21:16:59 CEST schrieb Herbert Albert:
Am Donnerstag, 25. April 2019, 18:56:15 CEST schrieb Hugo:
Hallo >Herbert, Am Mittwoch, 24. April 2019, 20:47:18 CEST schrieb Herbert Albert:>
hab nun das gleiche Problem mit der Firewall. In Yast Diensteverwaltung steht On Boot, aber Inaktiv. Wenn ich ihn aktiviere ist er beim nächsten reboot wieder deaktiviert. So einen Stress hatte ich beim alten Rechner nicht. Bestimmte Sachen, wie KDE-Connect scheinen nur mit aktiver Firewall zu gehen.
Wie sieht den journalctl info aus (option -r) ? Bei mir: # journalctl -r | grep firewall | head -20 Apr 25 18:18:21 ..,. kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 25 18:03:57 ..,..... systemd[1]: Started SuSEfirewall2 phase 2. Apr 25 18:03:57 ..,..... SuSEfirewall2[1254]: Firewall rules successfully set Apr 25 18:03:56 ..,..... SuSEfirewall2[1254]: Setting up rules from /etc/ sysconfig/SuSEfirewall2 ... Apr 25 18:03:55 ..,..... systemd[1]: Starting SuSEfirewall2 phase 2... Apr 25 18:03:54 ..,..... systemd[1]: Started SuSEfirewall2 phase 1. Apr 25 18:03:54 ..,..... SuSEfirewall2[943]: Firewall rules set to CLOSE. Apr 25 18:03:43 ..,..... systemd[1]: Starting SuSEfirewall2 phase 1... Apr 25 18:02:48 ..,. systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 25 18:02:45 ..,. systemd[1]: Stopping firewalld - dynamic firewall daemon...
für mich sieht das so aus: Aktiv ist SuSEfirewall2 ohne systemd ? firewalld startet, wird aber angehalten.
und yast2 bietet Konfiguration von firewalld an.
Das ist seltsam. erklärt aber vielleicht warum Deine Änderung (die woln für firewalld ist nicht geht.
Gruß Hugo Mahr Hallo Hugo,
wirst Du daraus schlau?
NeuerRechner:~ # journalctl -r | grep firewall | head -20 Apr 25 19:54:21 NeuerRechner systemd[1]: Started SuSEfirewall2 phase 2. Apr 25 19:54:21 NeuerRechner SuSEfirewall2[1370]: Firewall rules successfully set Apr 25 19:54:20 NeuerRechner SuSEfirewall2[1370]: using default zone 'ext' for interface eth0 Apr 25 19:54:20 NeuerRechner SuSEfirewall2[1370]: Setting up rules from /etc/ sysconfig/SuSEfirewall2 ... Apr 25 19:54:20 NeuerRechner systemd[1]: Starting SuSEfirewall2 phase 2... Apr 25 19:54:17 NeuerRechner systemd[1]: Started SuSEfirewall2 phase 1. Apr 25 19:54:17 NeuerRechner SuSEfirewall2[771]: Firewall rules set to CLOSE. Apr 25 19:54:16 NeuerRechner systemd[1]: Starting SuSEfirewall2 phase 1... Apr 24 22:19:30 NeuerRechner.fritz.box systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 24 22:19:28 NeuerRechner.fritz.box systemd[1]: Stopping firewalld - dynamic firewall daemon... Apr 24 22:04:43 NeuerRechner.fritz.box kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 24 22:04:41 NeuerRechner.fritz.box systemd[1]: Started firewalld - dynamic firewall daemon. Apr 24 22:04:41 NeuerRechner.fritz.box systemd[1]: Starting firewalld - dynamic firewall daemon... Apr 24 22:04:41 NeuerRechner.fritz.box systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 24 22:04:36 NeuerRechner.fritz.box systemd[1]: Stopping firewalld - dynamic firewall daemon... Apr 24 21:10:57 NeuerRechner.fritz.box kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 24 21:10:29 NeuerRechner.fritz.box systemd[1]: Started firewalld - dynamic firewall daemon. Apr 24 21:10:29 NeuerRechner.fritz.box systemd[1]: Starting firewalld - dynamic firewall daemon... Apr 24 21:09:23 NeuerRechner.fritz.box systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 24 21:09:19 NeuerRechner.fritz.box systemd[1]: Stopping firewalld - dynamic firewall daemon... NeuerRechner:~ #
Gruß
Herbert
firewalld und SUSE-Firewall funktionieren nicht zusammen..... -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 25. April 2019, 21:28:30 CEST schrieb Stephan Hemeier:
Am Donnerstag, 25. April 2019, 21:16:59 CEST schrieb Herbert Albert:
Am Donnerstag, 25. April 2019, 18:56:15 CEST schrieb Hugo:
Hallo >Herbert, Am Mittwoch, 24. April 2019, 20:47:18 CEST schrieb Herbert Albert:>
hab nun das gleiche Problem mit der Firewall. In Yast Diensteverwaltung steht On Boot, aber Inaktiv. Wenn ich ihn aktiviere ist er beim nächsten reboot wieder deaktiviert. So einen Stress hatte ich beim alten Rechner nicht. Bestimmte Sachen, wie KDE-Connect scheinen nur mit aktiver Firewall zu gehen.
Wie sieht den journalctl info aus (option -r) ? Bei mir: # journalctl -r | grep firewall | head -20 Apr 25 18:18:21 ..,. kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 25 18:03:57 ..,..... systemd[1]: Started SuSEfirewall2 phase 2. Apr 25 18:03:57 ..,..... SuSEfirewall2[1254]: Firewall rules successfully set Apr 25 18:03:56 ..,..... SuSEfirewall2[1254]: Setting up rules from /etc/ sysconfig/SuSEfirewall2 ... Apr 25 18:03:55 ..,..... systemd[1]: Starting SuSEfirewall2 phase 2... Apr 25 18:03:54 ..,..... systemd[1]: Started SuSEfirewall2 phase 1. Apr 25 18:03:54 ..,..... SuSEfirewall2[943]: Firewall rules set to CLOSE. Apr 25 18:03:43 ..,..... systemd[1]: Starting SuSEfirewall2 phase 1... Apr 25 18:02:48 ..,. systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 25 18:02:45 ..,. systemd[1]: Stopping firewalld - dynamic firewall daemon...
für mich sieht das so aus: Aktiv ist SuSEfirewall2
ohne systemd ? firewalld startet, wird aber angehalten.
und yast2 bietet Konfiguration von firewalld an.
Das ist seltsam. erklärt aber vielleicht
warum Deine Änderung (die woln für firewalld ist
nicht geht.
Gruß
Hugo Mahr
Hallo Hugo,
wirst Du daraus schlau?
NeuerRechner:~ # journalctl -r | grep firewall | head -20 Apr 25 19:54:21 NeuerRechner systemd[1]: Started SuSEfirewall2 phase 2. Apr 25 19:54:21 NeuerRechner SuSEfirewall2[1370]: Firewall rules successfully set Apr 25 19:54:20 NeuerRechner SuSEfirewall2[1370]: using default zone 'ext' for interface eth0 Apr 25 19:54:20 NeuerRechner SuSEfirewall2[1370]: Setting up rules from /etc/ sysconfig/SuSEfirewall2 ... Apr 25 19:54:20 NeuerRechner systemd[1]: Starting SuSEfirewall2 phase 2... Apr 25 19:54:17 NeuerRechner systemd[1]: Started SuSEfirewall2 phase 1. Apr 25 19:54:17 NeuerRechner SuSEfirewall2[771]: Firewall rules set to CLOSE. Apr 25 19:54:16 NeuerRechner systemd[1]: Starting SuSEfirewall2 phase 1... Apr 24 22:19:30 NeuerRechner.fritz.box systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 24 22:19:28 NeuerRechner.fritz.box systemd[1]: Stopping firewalld - dynamic firewall daemon... Apr 24 22:04:43 NeuerRechner.fritz.box kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 24 22:04:41 NeuerRechner.fritz.box systemd[1]: Started firewalld - dynamic firewall daemon. Apr 24 22:04:41 NeuerRechner.fritz.box systemd[1]: Starting firewalld - dynamic firewall daemon... Apr 24 22:04:41 NeuerRechner.fritz.box systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 24 22:04:36 NeuerRechner.fritz.box systemd[1]: Stopping firewalld - dynamic firewall daemon... Apr 24 21:10:57 NeuerRechner.fritz.box kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 24 21:10:29 NeuerRechner.fritz.box systemd[1]: Started firewalld - dynamic firewall daemon. Apr 24 21:10:29 NeuerRechner.fritz.box systemd[1]: Starting firewalld - dynamic firewall daemon... Apr 24 21:09:23 NeuerRechner.fritz.box systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 24 21:09:19 NeuerRechner.fritz.box systemd[1]: Stopping firewalld - dynamic firewall daemon... NeuerRechner:~ #
Gruß
Herbert
firewalld und SUSE-Firewall funktionieren nicht zusammen..... ok, und was schlägst Du vor? den Dienst firewalld auf manuell setzen?
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 25. April 2019, 21:28:30 CEST schrieb Stephan Hemeier:
Am Donnerstag, 25. April 2019, 21:16:59 CEST schrieb Herbert Albert:
Am Donnerstag, 25. April 2019, 18:56:15 CEST schrieb Hugo:
Hallo >Herbert, Am Mittwoch, 24. April 2019, 20:47:18 CEST schrieb Herbert Albert:>
hab nun das gleiche Problem mit der Firewall. In Yast Diensteverwaltung steht On Boot, aber Inaktiv. Wenn ich ihn aktiviere ist er beim nächsten reboot wieder deaktiviert. So einen Stress hatte ich beim alten Rechner nicht. Bestimmte Sachen, wie KDE-Connect scheinen nur mit aktiver Firewall zu gehen.
Wie sieht den journalctl info aus (option -r) ? Bei mir: # journalctl -r | grep firewall | head -20 Apr 25 18:18:21 ..,. kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 25 18:03:57 ..,..... systemd[1]: Started SuSEfirewall2 phase 2. Apr 25 18:03:57 ..,..... SuSEfirewall2[1254]: Firewall rules successfully set Apr 25 18:03:56 ..,..... SuSEfirewall2[1254]: Setting up rules from /etc/ sysconfig/SuSEfirewall2 ... Apr 25 18:03:55 ..,..... systemd[1]: Starting SuSEfirewall2 phase 2... Apr 25 18:03:54 ..,..... systemd[1]: Started SuSEfirewall2 phase 1. Apr 25 18:03:54 ..,..... SuSEfirewall2[943]: Firewall rules set to CLOSE. Apr 25 18:03:43 ..,..... systemd[1]: Starting SuSEfirewall2 phase 1... Apr 25 18:02:48 ..,. systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 25 18:02:45 ..,. systemd[1]: Stopping firewalld - dynamic firewall daemon...
für mich sieht das so aus: Aktiv ist SuSEfirewall2
ohne systemd ? firewalld startet, wird aber angehalten.
und yast2 bietet Konfiguration von firewalld an.
Das ist seltsam. erklärt aber vielleicht
warum Deine Änderung (die woln für firewalld ist
nicht geht.
Gruß
Hugo Mahr
Hallo Hugo,
wirst Du daraus schlau?
NeuerRechner:~ # journalctl -r | grep firewall | head -20 Apr 25 19:54:21 NeuerRechner systemd[1]: Started SuSEfirewall2 phase 2. Apr 25 19:54:21 NeuerRechner SuSEfirewall2[1370]: Firewall rules successfully set Apr 25 19:54:20 NeuerRechner SuSEfirewall2[1370]: using default zone 'ext' for interface eth0 Apr 25 19:54:20 NeuerRechner SuSEfirewall2[1370]: Setting up rules from /etc/ sysconfig/SuSEfirewall2 ... Apr 25 19:54:20 NeuerRechner systemd[1]: Starting SuSEfirewall2 phase 2... Apr 25 19:54:17 NeuerRechner systemd[1]: Started SuSEfirewall2 phase 1. Apr 25 19:54:17 NeuerRechner SuSEfirewall2[771]: Firewall rules set to CLOSE. Apr 25 19:54:16 NeuerRechner systemd[1]: Starting SuSEfirewall2 phase 1... Apr 24 22:19:30 NeuerRechner.fritz.box systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 24 22:19:28 NeuerRechner.fritz.box systemd[1]: Stopping firewalld - dynamic firewall daemon... Apr 24 22:04:43 NeuerRechner.fritz.box kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 24 22:04:41 NeuerRechner.fritz.box systemd[1]: Started firewalld - dynamic firewall daemon. Apr 24 22:04:41 NeuerRechner.fritz.box systemd[1]: Starting firewalld - dynamic firewall daemon... Apr 24 22:04:41 NeuerRechner.fritz.box systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 24 22:04:36 NeuerRechner.fritz.box systemd[1]: Stopping firewalld - dynamic firewall daemon... Apr 24 21:10:57 NeuerRechner.fritz.box kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Apr 24 21:10:29 NeuerRechner.fritz.box systemd[1]: Started firewalld - dynamic firewall daemon. Apr 24 21:10:29 NeuerRechner.fritz.box systemd[1]: Starting firewalld - dynamic firewall daemon... Apr 24 21:09:23 NeuerRechner.fritz.box systemd[1]: Stopped firewalld - dynamic firewall daemon. Apr 24 21:09:19 NeuerRechner.fritz.box systemd[1]: Stopping firewalld - dynamic firewall daemon... NeuerRechner:~ #
Gruß
Herbert
firewalld und SUSE-Firewall funktionieren nicht zusammen..... wenn firewalld inaktiv ist lässt sich per Yast die SuSE Firewall gar nicht öffnen: Fehler Verbindung mit Firewall fehlgeschlagen. Stellen Sie sicher, dass der Dienstkorrekt gestartet wurde, und versuchen Sie es erneut.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 25. April 2019, 21:35:00 CEST schrieb Herbert Albert:
wenn firewalld inaktiv ist lässt sich per Yast die SuSE Firewall gar nicht öffnen: Fehler Verbindung mit Firewall fehlgeschlagen. Stellen Sie sicher, dass der Dienstkorrekt gestartet wurde, und versuchen Sie es erneut.
Poste: zypper se -si firewall -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 25. April 2019, 21:38:58 CEST schrieb Stephan Hemeier:
Am Donnerstag, 25. April 2019, 21:35:00 CEST schrieb Herbert Albert:
wenn firewalld inaktiv ist lässt sich per Yast die SuSE Firewall gar nicht öffnen: Fehler Verbindung mit Firewall fehlgeschlagen. Stellen Sie sicher, dass der Dienstkorrekt gestartet wurde, und versuchen Sie es erneut.
Poste: zypper se -si firewall
:~ # zypper se -si firewall Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+------------------+---------+--------------------+-------- +-------------------------- i+ | SuSEfirewall2 | package | 3.6.378-lp150.1.15 | noarch | openSUSE- Leap-15.0-Oss i+ | firewall-config | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i+ | firewall-macros | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i | firewalld | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i+ | firewalld-lang | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i+ | python3-firewall | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i | yast2-firewall | package | 4.0.26-lp150.2.3.1 | noarch | openSUSE- Leap-15.0-Update -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 25. April 2019, 21:43:46 CEST schrieb Herbert Albert:
Am Donnerstag, 25. April 2019, 21:38:58 CEST schrieb Stephan Hemeier:
Am Donnerstag, 25. April 2019, 21:35:00 CEST schrieb Herbert Albert:
wenn firewalld inaktiv ist lässt sich per Yast die SuSE Firewall gar nicht öffnen: Fehler Verbindung mit Firewall fehlgeschlagen. Stellen Sie sicher, dass der Dienstkorrekt gestartet wurde, und versuchen Sie es erneut.
Poste: zypper se -si firewall
:~ # zypper se -si firewall Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository ---+------------------+---------+--------------------+-------- +-------------------------- i+ | SuSEfirewall2 | package | 3.6.378-lp150.1.15 | noarch | openSUSE- Leap-15.0-Oss i+ | firewall-config | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i+ | firewall-macros | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i | firewalld | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i+ | firewalld-lang | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i+ | python3-firewall | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i | yast2-firewall | package | 4.0.26-lp150.2.3.1 | noarch | openSUSE- Leap-15.0-Update
Und wie ich schon sagte, SUSE-Firewall und firewalld funktionieren nicht zusammen.... Du musst dich schon von einem trennen. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 25. April 2019, 21:45:19 CEST schrieb Stephan Hemeier:
Am Donnerstag, 25. April 2019, 21:43:46 CEST schrieb Herbert Albert:
Am Donnerstag, 25. April 2019, 21:38:58 CEST schrieb Stephan Hemeier:
Am Donnerstag, 25. April 2019, 21:35:00 CEST schrieb Herbert Albert:
wenn firewalld inaktiv ist lässt sich per Yast die SuSE Firewall gar nicht öffnen: Fehler Verbindung mit Firewall fehlgeschlagen. Stellen Sie sicher, dass der Dienstkorrekt gestartet wurde, und versuchen Sie es erneut.
Poste: zypper se -si firewall : :~ # zypper se -si firewall
Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository ---+------------------+---------+--------------------+-------- +-------------------------- i+ | SuSEfirewall2 | package | 3.6.378-lp150.1.15 | noarch | openSUSE- Leap-15.0-Oss i+ | firewall-config | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i+ | firewall-macros | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i | firewalld | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i+ | firewalld-lang | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i+ | python3-firewall | package | 0.5.5-lp150.2.22.2 | noarch | openSUSE- Leap-15.0-Update i | yast2-firewall | package | 4.0.26-lp150.2.3.1 | noarch | openSUSE- Leap-15.0-Update
Und wie ich schon sagte, SUSE-Firewall und firewalld funktionieren nicht zusammen.... Du musst dich schon von einem trennen. wenn ich firewalld und Anhang per Yast deinstalliere, dann will ein Klick auf das Yast Icon Firewall genau diesen wieder. Kann also nur SuSEfirewall2 deinstallieren.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 25. April 2019, 21:55:37 CEST schrieb Herbert Albert:
wenn ich firewalld und Anhang per Yast deinstalliere, dann will ein Klick auf das Yast Icon Firewall genau diesen wieder. Kann also nur SuSEfirewall2 deinstallieren.
Weil yast-firewall sich jetzt auf firewalld bezieht.-........... -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Donnerstag, 25. April 2019, 22:00:58 CEST schrieb Stephan Hemeier:
Am Donnerstag, 25. April 2019, 21:55:37 CEST schrieb Herbert Albert:
wenn ich firewalld und Anhang per Yast deinstalliere, dann will ein Klick auf das Yast Icon Firewall genau diesen wieder. Kann also nur SuSEfirewall2 deinstallieren.
Weil yast-firewall sich jetzt auf firewalld bezieht.-........... Na, dann ist alles klar.
Trotzdem. Ich habe auf 2 Systemen von DVD installiert. Und da war ursprünglich SuSEfirewall2. Erst ab ca. 2018-06-22 sehe ich in /var/log/zypp/history firewalld-0.5.3-lp150.1.1.noarch.rpm installed ok Und ich denke, das war so nicht von mir bemerkt worden :-( Jetzt will ich susefirewall2-to-firewalld - Basic SuSEfirewall2 to FirewallD migration script probieren,, ev. susefirewall2 löschen.. An Herbert: Ich wollte aus journalctl sehen, ob Du auch dieses Problem hast. Die Ausgabe ist wohl übersiichtlicher mit # journalctl -b | grep -Ei 'starting SuSEfirewall2|started firewalld' Viele Grüße Hugo Mahr -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Freitag, 26. April 2019, 11:36:04 CEST schrieb Hugo:
Hallo,
Am Donnerstag, 25. April 2019, 22:00:58 CEST schrieb Stephan Hemeier:
Am Donnerstag, 25. April 2019, 21:55:37 CEST schrieb Herbert Albert:
wenn ich firewalld und Anhang per Yast deinstalliere, dann will ein Klick auf das Yast Icon Firewall genau diesen wieder. Kann also nur SuSEfirewall2 deinstallieren.
Weil yast-firewall sich jetzt auf firewalld bezieht.-...........
Na, dann ist alles klar.
Trotzdem. Ich habe auf 2 Systemen von DVD installiert. Und da war ursprünglich SuSEfirewall2. Erst ab ca. 2018-06-22 sehe ich in /var/log/zypp/history firewalld-0.5.3-lp150.1.1.noarch.rpm installed ok
Und ich denke, das war so nicht von mir bemerkt worden :-(
Jetzt will ich susefirewall2-to-firewalld - Basic SuSEfirewall2 to FirewallD migration script probieren,, ev. susefirewall2 löschen..
An Herbert: Ich wollte aus journalctl sehen, ob Du auch dieses Problem hast. Die Ausgabe ist wohl übersiichtlicher mit # journalctl -b | grep -Ei 'starting SuSEfirewall2|started firewalld'
Viele Grüße Hugo Mahr ~ # journalctl -b | grep -Ei 'starting SuSEfirewall2|started firewalld' Apr 26 18:34:17 NeuerRechner systemd[1]: Started firewalld - dynamic firewall daemon. Apr 26 19:18:41 NeuerRechner systemd[1]: Started firewalld - dynamic firewall daemon.
Der firewalld scheint nun nach dem Start heute zu laufen. Dafür macht mir die Samba-Freigabe meiner home-verzeichnisse Probleme, bekomme keinen Kontakt mehr in win zu \\NeuerRechner\User. NeuerRechner:~ # systemctl start smb nmb NeuerRechner:~ # systemctl status smb nmb ? smb.service - Samba SMB Daemon Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2019-04-26 19:18:50 CEST; 12min ago Process: 7346 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile (code=exited, status=0/SUCCESS) Main PID: 7350 (smbd) Status: "smbd: ready to serve connections..." Tasks: 4 (limit: 4915) CGroup: /system.slice/smb.service ??7350 /usr/sbin/smbd --foreground --no-process-group ??7352 /usr/sbin/smbd --foreground --no-process-group ??7353 /usr/sbin/smbd --foreground --no-process-group ??7354 /usr/sbin/smbd --foreground --no-process-group Apr 26 19:23:48 NeuerRechner smbd[7908]: [2019/04/26 19:23:48.449440, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7908]: Denied connection from 192.168.178.37 (192.168.178.37) Apr 26 19:23:48 NeuerRechner smbd[7909]: [2019/04/26 19:23:48.451821, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7909]: Denied connection from 192.168.178.37 (192.168.178.37) Apr 26 19:23:48 NeuerRechner smbd[7910]: [2019/04/26 19:23:48.470340, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7910]: Denied connection from 192.168.178.37 (192.168.178.37) Apr 26 19:23:48 NeuerRechner smbd[7911]: [2019/04/26 19:23:48.474411, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7911]: Denied connection from 192.168.178.37 (192.168.178.37) Apr 26 19:23:48 NeuerRechner smbd[7913]: [2019/04/26 19:23:48.476912, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7913]: Denied connection from 192.168.178.37 (192.168.178.37) ? nmb.service - Samba NMB Daemon Loaded: loaded (/usr/lib/systemd/system/nmb.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2019-04-26 19:18:50 CEST; 12min ago Main PID: 7343 (nmbd) Status: "nmbd: ready to serve connections..." Tasks: 2 (limit: 4915) CGroup: /system.slice/nmb.service ??7343 /usr/sbin/nmbd --foreground --no-process-group ??7344 /usr/sbin/nmbd --foreground --no-process-group Apr 26 19:20:01 NeuerRechner nmbd[7343]: Apr 26 19:20:01 NeuerRechner nmbd[7343]: Samba name server NeuerRechner has stopped being a local master browser for workgroup ARBEITSGRUPPE on subnet 192.168.178.37 Apr 26 19:20:01 NeuerRechner nmbd[7343]: Apr 26 19:20:01 NeuerRechner nmbd[7343]: ***** Apr 26 19:20:18 NeuerRechner nmbd[7343]: [2019/04/26 19:20:18.998919, 0] ../ source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2) Apr 26 19:20:18 NeuerRechner nmbd[7343]: ***** Apr 26 19:20:18 NeuerRechner nmbd[7343]: Apr 26 19:20:18 NeuerRechner nmbd[7343]: Samba name server NeuerRechner is now a local master browser for workgroup ARBEITSGRUPPE on subnet 192.168.178.37 Apr 26 19:20:18 NeuerRechner nmbd[7343]: Apr 26 19:20:18 NeuerRechner nmbd[7343]: ***** NeuerRechner:~ # Was bedeutet hier in der ZeileLoaded: loaded (/usr/lib/systemd/system/ smb.service; enabled; vendor preset: disabled) "vendor preset: disabled"? Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Herbert, hallo Liste, Habe mal den Betreff erweitert, weil ich denke, ein neuer thread ist hier angebracht. Am Freitag, 26. April 2019, 19:34:55 CEST schrieb Herbert Albert:
Am Freitag, 26. April 2019, 11:36:04 CEST schrieb Hugo:
Hallo,
Am Donnerstag, 25. April 2019, 22:00:58 CEST schrieb Stephan Hemeier:
Am Donnerstag, 25. April 2019, 21:55:37 CEST schrieb Herbert Albert:
wenn ich firewalld und Anhang per Yast deinstalliere, dann will ein Klick auf das Yast Icon Firewall genau diesen wieder. Kann also nur SuSEfirewall2 deinstallieren.
Weil yast-firewall sich jetzt auf firewalld bezieht.-...........
Na, dann ist alles klar.
Trotzdem. Ich habe auf 2 Systemen von DVD installiert. Und da war ursprünglich SuSEfirewall2. Erst ab ca. 2018-06-22 sehe ich in /var/log/zypp/history firewalld-0.5.3-lp150.1.1.noarch.rpm installed ok
Und ich denke, das war so nicht von mir bemerkt worden :-(
Jetzt will ich susefirewall2-to-firewalld - Basic SuSEfirewall2 to FirewallD migration script probieren,, ev. susefirewall2 löschen.. Rückmeldung: Geht.
An Herbert: Ich wollte aus journalctl sehen, ob Du auch dieses Problem hast. Die Ausgabe ist wohl übersiichtlicher mit
# journalctl -b | grep -Ei 'starting SuSEfirewall2|started
firewalld'
Viele Grüße
Hugo Mahr
~ # journalctl -b | grep -Ei 'starting SuSEfirewall2|started firewalld' Apr 26 18:34:17 NeuerRechner systemd[1]: Started firewalld - dynamic firewall daemon. Apr 26 19:18:41 NeuerRechner systemd[1]: Started firewalld - dynamic firewall daemon.
Der firewalld scheint nun nach dem Start heute zu laufen. Gratuliere.
Dafür macht mir die Samba-Freigabe meiner home-verzeichnisse Probleme, bekomme keinen Kontakt mehr in win zu \\NeuerRechner\User.
NeuerRechner:~ # systemctl start smb nmb NeuerRechner:~ # systemctl status smb nmb ? smb.service - Samba SMB Daemon Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor preset: disabled) IMHO - falls das hier passt: Frei übersetzt - Da hat ein 'vendor' samba service bereitgestellt. Und Vorgabe ist ausgeschaltet (preset: disabled). Trotzdem ist der aktiv (enabled). Und der service ist geladen (loaded). Er könnte gestartet werden. Active: active (running) since Fri 2019-04-26 19:18:50 CEST; 12min ago Aha, läuft seit 12 Minuten. Process: 7346 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile (code=exited, status=0/SUCCESS) Main PID: 7350 (smbd) Status: "smbd: ready to serve connections..." Tasks: 4 (limit: 4915) CGroup: /system.slice/smb.service ??7350 /usr/sbin/smbd --foreground --no-process-group ??7352 /usr/sbin/smbd --foreground --no-process-group ??7353 /usr/sbin/smbd --foreground --no-process-group ??7354 /usr/sbin/smbd --foreground --no-process-group
Benutze kein samba - sieht aber gut aus.
Apr 26 19:23:48 NeuerRechner smbd[7908]: [2019/04/26 19:23:48.449440, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7908]: Denied connection from 192.168.178.37 (192.168.178.37) Das klingt doch so, als würde die firewall diese Verbindung verbieten. Gerade wenn es vorher mit firewall2 ging. Vielleicht mal firewall ausschalten? Ich gehe davon aus das 192.168.178.37 ein anderer Rechner (dein Win) als 'NeuerRechner' ist. Apr 26 19:23:48 NeuerRechner smbd[7909]: [2019/04/26 19:23:48.451821, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7909]: Denied connection from 192.168.178.37 (192.168.178.37) Apr 26 19:23:48 NeuerRechner smbd[7910]: [2019/04/26 19:23:48.470340, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7910]: Denied connection from 192.168.178.37 (192.168.178.37) Apr 26 19:23:48 NeuerRechner smbd[7911]: [2019/04/26 19:23:48.474411, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7911]: Denied connection from 192.168.178.37 (192.168.178.37) Apr 26 19:23:48 NeuerRechner smbd[7913]: [2019/04/26 19:23:48.476912, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7913]: Denied connection from 192.168.178.37 (192.168.178.37) 9 mal dieselbe Meldung.
? nmb.service - Samba NMB Daemon Loaded: loaded (/usr/lib/systemd/system/nmb.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2019-04-26 19:18:50 CEST; 12min ago Main PID: 7343 (nmbd) Status: "nmbd: ready to serve connections..." Tasks: 2 (limit: 4915) CGroup: /system.slice/nmb.service ??7343 /usr/sbin/nmbd --foreground --no-process-group ??7344 /usr/sbin/nmbd --foreground --no-process-group
Apr 26 19:20:01 NeuerRechner nmbd[7343]: Apr 26 19:20:01 NeuerRechner nmbd[7343]: Samba name server NeuerRechner has stopped being a local master browser for workgroup ARBEITSGRUPPE on subnet 192.168.178.37 Apr 26 19:20:01 NeuerRechner nmbd[7343]: Apr 26 19:20:01 NeuerRechner nmbd[7343]: ***** Apr 26 19:20:18 NeuerRechner nmbd[7343]: [2019/04/26 19:20:18.998919, 0] ../ source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2) Apr 26 19:20:18 NeuerRechner nmbd[7343]: ***** Apr 26 19:20:18 NeuerRechner nmbd[7343]: Apr 26 19:20:18 NeuerRechner nmbd[7343]: Samba name server NeuerRechner is now a local master browser for workgroup ARBEITSGRUPPE on subnet 192.168.178.37 Apr 26 19:20:18 NeuerRechner nmbd[7343]: Apr 26 19:20:18 NeuerRechner nmbd[7343]: ***** NeuerRechner:~ #
Was bedeutet hier in der ZeileLoaded: loaded (/usr/lib/systemd/system/ smb.service; enabled; vendor preset: disabled) "vendor preset: disabled"?
s.o. Viel Erfolg mit samba. Gruß Hugo Mahr -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Samstag, 27. April 2019, 10:23:08 CEST schrieb Hugo:
Hallo Herbert, hallo Liste, Habe mal den Betreff erweitert, weil ich denke, ein neuer thread ist hier angebracht.
Am Freitag, 26. April 2019, 19:34:55 CEST schrieb Herbert Albert:
Am Freitag, 26. April 2019, 11:36:04 CEST schrieb Hugo:
Hallo,
Am Donnerstag, 25. April 2019, 22:00:58 CEST schrieb Stephan Hemeier:
Am Donnerstag, 25. April 2019, 21:55:37 CEST schrieb Herbert Albert:
wenn ich firewalld und Anhang per Yast deinstalliere, dann will ein Klick auf das Yast Icon Firewall genau diesen wieder. Kann also nur SuSEfirewall2 deinstallieren.
Weil yast-firewall sich jetzt auf firewalld bezieht.-...........
Na, dann ist alles klar.
Trotzdem. Ich habe auf 2 Systemen von DVD installiert. Und da war ursprünglich SuSEfirewall2. Erst ab ca. 2018-06-22 sehe ich in /var/log/zypp/history firewalld-0.5.3-lp150.1.1.noarch.rpm installed ok
Und ich denke, das war so nicht von mir bemerkt worden :-(
Jetzt will ich susefirewall2-to-firewalld - Basic SuSEfirewall2 to FirewallD migration script probieren,, ev. susefirewall2 löschen..
Rückmeldung: Geht.
An Herbert: Ich wollte aus journalctl sehen, ob Du auch dieses Problem hast. Die Ausgabe ist wohl übersiichtlicher mit
# journalctl -b | grep -Ei 'starting SuSEfirewall2|started
firewalld'
Viele Grüße
Hugo Mahr
~ # journalctl -b | grep -Ei 'starting SuSEfirewall2|started firewalld' Apr 26 18:34:17 NeuerRechner systemd[1]: Started firewalld - dynamic firewall daemon. Apr 26 19:18:41 NeuerRechner systemd[1]: Started firewalld - dynamic firewall daemon.
Der firewalld scheint nun nach dem Start heute zu laufen.
Gratuliere.
Dafür macht mir die Samba-Freigabe meiner home-verzeichnisse Probleme, bekomme keinen Kontakt mehr in win zu \\NeuerRechner\User.
NeuerRechner:~ # systemctl start smb nmb NeuerRechner:~ # systemctl status smb nmb ? smb.service - Samba SMB Daemon
Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor
preset: disabled)
IMHO - falls das hier passt: Frei übersetzt - Da hat ein 'vendor' samba service bereitgestellt. Und Vorgabe ist ausgeschaltet (preset: disabled). Trotzdem ist der aktiv (enabled). Und der service ist geladen (loaded). Er könnte gestartet werden.
Active: active (running) since Fri 2019-04-26 19:18:50 CEST; 12min ago
Aha, läuft seit 12 Minuten.
Process: 7346 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile
(code=exited, status=0/SUCCESS)
Main PID: 7350 (smbd)
Status: "smbd: ready to serve connections..."
Tasks: 4 (limit: 4915)
CGroup: /system.slice/smb.service
??7350 /usr/sbin/smbd --foreground --no-process-group ??7352 /usr/sbin/smbd --foreground --no-process-group ??7353 /usr/sbin/smbd --foreground --no-process-group ??7354 /usr/sbin/smbd --foreground --no-process-group
Benutze kein samba - sieht aber gut aus.
Apr 26 19:23:48 NeuerRechner smbd[7908]: [2019/04/26 19:23:48.449440, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7908]: Denied connection from 192.168.178.37 (192.168.178.37)
Das klingt doch so, als würde die firewall diese Verbindung verbieten. Gerade wenn es vorher mit firewall2 ging. Vielleicht mal firewall ausschalten? Ich gehe davon aus das 192.168.178.37 ein anderer Rechner (dein Win) als 'NeuerRechner' ist.
Apr 26 19:23:48 NeuerRechner smbd[7909]: [2019/04/26 19:23:48.451821, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7909]: Denied connection from 192.168.178.37 (192.168.178.37) Apr 26 19:23:48 NeuerRechner smbd[7910]: [2019/04/26 19:23:48.470340, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7910]: Denied connection from 192.168.178.37 (192.168.178.37) Apr 26 19:23:48 NeuerRechner smbd[7911]: [2019/04/26 19:23:48.474411, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7911]: Denied connection from 192.168.178.37 (192.168.178.37) Apr 26 19:23:48 NeuerRechner smbd[7913]: [2019/04/26 19:23:48.476912, 0] ../ lib/util/access.c:365(allow_access) Apr 26 19:23:48 NeuerRechner smbd[7913]: Denied connection from 192.168.178.37 (192.168.178.37)
9 mal dieselbe Meldung.
? nmb.service - Samba NMB Daemon
Loaded: loaded (/usr/lib/systemd/system/nmb.service; enabled; vendor
preset: disabled)
Active: active (running) since Fri 2019-04-26 19:18:50 CEST; 12min ago
Main PID: 7343 (nmbd)
Status: "nmbd: ready to serve connections..."
Tasks: 2 (limit: 4915)
CGroup: /system.slice/nmb.service
??7343 /usr/sbin/nmbd --foreground --no-process-group ??7344 /usr/sbin/nmbd --foreground --no-process-group
Apr 26 19:20:01 NeuerRechner nmbd[7343]: Apr 26 19:20:01 NeuerRechner nmbd[7343]: Samba name server NeuerRechner has stopped being a local master browser for workgroup ARBEITSGRUPPE on subnet 192.168.178.37 Apr 26 19:20:01 NeuerRechner nmbd[7343]: Apr 26 19:20:01 NeuerRechner nmbd[7343]: ***** Apr 26 19:20:18 NeuerRechner nmbd[7343]: [2019/04/26 19:20:18.998919, 0] ../ source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2) Apr 26 19:20:18 NeuerRechner nmbd[7343]: ***** Apr 26 19:20:18 NeuerRechner nmbd[7343]: Apr 26 19:20:18 NeuerRechner nmbd[7343]: Samba name server NeuerRechner is now a local master browser for workgroup ARBEITSGRUPPE on subnet 192.168.178.37 Apr 26 19:20:18 NeuerRechner nmbd[7343]: Apr 26 19:20:18 NeuerRechner nmbd[7343]: ***** NeuerRechner:~ #
Was bedeutet hier in der ZeileLoaded: loaded (/usr/lib/systemd/system/ smb.service; enabled; vendor preset: disabled) "vendor preset: disabled"?
s.o. Viel Erfolg mit samba.
Gruß Hugo Mahr hab's gelöst, waren doch Altlasten beim Übertrag.
Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (13)
-
Christian Boltz -
h.albert＠odn.de -
Herbert Albert
-
Hugo -
Jan-Uwe Koegel -
Klaus Klose -
Manfred Kreisl -
Martin Deppe -
Michael Eschweiler -
Michael Höhne -
Richard Kraut -
Stephan Hemeier -
Yamaban