# systemd & udev in chroot-Umgebung

## uhai

Ich bin immer noch am Neu-Aufsetzen meines Systems. Nach dem reboot bemängelt systemctl das nicht laufende udev. mit /etc/init.d/udev start erhalte ich aber die Meldung, udev liefe schon. Anscheinend erkennt systemctl das laufende udev nicht. Die udev-Regeln (/etc/udev/rules.d/ habe ich bereits entfernt.

```

 eix -I udev

[I] sys-apps/udevil

     Available versions:  0.4.1

     Installed versions:  0.4.1(03:40:17 10/02/13)

     Homepage:            http://ignorantguru.github.com/udevil/

     Description:         mount and unmount removable devices without a password

[I] sys-fs/udev-init-scripts

     Available versions:  26^t **9999^t

     Installed versions:  26^t(20:40:45 10/06/13)

     Homepage:            http://www.gentoo.org

     Description:         udev startup scripts for openrc

[I] virtual/udev

     Available versions:  200 (~)206-r3 {gudev hwdb introspection keymap +kmod selinux static-libs ABI_MIPS="n32 n64 o32" ABI_X86="32 64 x32"}

     Installed versions:  206-r3(14:33:59 10/06/13)(gudev introspection kmod -selinux -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_X86="64 -32 -x32")

     Description:         Virtual to select between sys-fs/udev and sys-fs/eudev

```

```
eix -I systemd

[I] sys-apps/gentoo-systemd-integration

     Available versions:  1 ~2 **9999

     Installed versions:  1(20:31:00 10/01/13)

     Homepage:            https://bitbucket.org/mgorny/gentoo-systemd-integration

     Description:         systemd integration files for Gentoo

[I] sys-apps/systemd

     Available versions:  204-r1 (~)204-r2 (~)207-r2 (~)208-r1(0/1) **9999(0/1) {acl audit cryptsetup doc +filecaps +firmware-loader gcrypt gudev http introspection keymap +kmod lzma openrc pam policykit python qrcode selinux static-libs tcpd test vanilla xattr ABI_MIPS="n32 n64 o32" ABI_X86="32 64 x32" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7"}

     Installed versions:  208-r1(20:37:10 10/06/13)(acl filecaps firmware-loader gudev introspection kmod openrc pam policykit python tcpd -audit -cryptsetup -doc -gcrypt -http -lzma -qrcode -selinux -test -vanilla -xattr ABI_MIPS="-n32 -n64 -o32" ABI_X86="64 -32 -x32" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7")

     Homepage:            http://www.freedesktop.org/wiki/Software/systemd

     Description:         System and service manager for Linux

```

Im chroot kann ich systemctl nicht nutzen. Wie bekomme ich das in den Griff?

uhai

----------

## uhai

 *uhai wrote:*   

> Ich bin immer noch am Neu-Aufsetzen meines Systems. Nach dem reboot bemängelt systemctl das nicht laufende udev. mit /etc/init.d/udev start erhalte ich aber die Meldung, udev liefe schon. Anscheinend erkennt systemctl das laufende udev nicht. Die udev-Regeln (/etc/udev/rules.d/ habe ich bereits entfernt.
> 
> ```
> 
>  eix -I udev
> ...

 

Nach dem Reboot habe ich keinen dbus laufen, daher funktioniert systemctl nicht. dbus kann ich nicht aktivieren... Welche Angaben braucht Ihr?

----------

## syn0ptik

hallo,

Du müss anschließen systemd mit init systeme.

```
ln -s /usr/lib/systemd/systemd /sbin/init
```

Können du antworten hier ob anfangt das systeme arbeit?

----------

## uhai

```
(chroot) livecd / # ln -s /usr/lib/systemd/systemd /sbin/init

ln: failed to create symbolic link '/sbin/init': File exists

```

Schade, das war es nicht... Danke synOptik für den Tip. Weitere Ideen?

uhai

PS: Ich bin bis jetzt immer davon ausgegangen, dass dbus von systemd hestartet wird. Stimmt das, oder muss dbus vorher schon laufen, damit systemd arbeitet? Dbus ist bei mir im default runlevel... nur systemd erkennt ihn nicht.??

----------

## syn0ptik

ja, du muss benutzen nur systemd. Die systemd neu init systme, weil du muss machen:

```
ln -sf /usr/lib/systemd/systemd /sbin/init 
```

Und reboot die rechner mit das systeme root.

----------

## franzf

 *syn0ptik wrote:*   

> ja, du muss benutzen nur systemd. Die systemd neu init systme, weil du muss machen:
> 
> ```
> ln -sf /usr/lib/systemd/systemd /sbin/init 
> ```
> ...

 

/sbin/init ist eine Datei und kein symlink. init kommt mit sys-apps/sysvinit. Es sieht so aus als bootest du noch immer mit openrc. systemd-Doku lesen, du musst deine bootmanager.config (z.B. /boot/grub/grub.conf) anpassen - wobei es da mittlerweile mit den Gentoo-sources auch eine Option gibt, die automatisch systemd als init verwendet (ab 3.11?)

udev starten sollte nicht notwendig sein, wird eigentlich automatsch ins runlevel genommen, systemd IMHO sowieso nicht. Damit du systemctl auch im chroot verwenden kannst musst du "--no-reload" angeben (verwende kein systemd, aber google war in 2 Minuten mit der Lösung zur Stelle...)

----------

## syn0ptik

 *Quote:*   

> udev starten sollte nicht notwendig sein, wird eigentlich automatsch ins runlevel genommen, systemd IMHO sowieso nicht.

 

ja, aber

 *Quote:*   

> systemd is a modern sysvinit & RC replacement for Linux systems. It is supported in Gentoo as an alternate init system. 

 

was dann, gibts ein punkte

```
kernel /vmlinuz root=/dev/sda2 init=/usr/lib/systemd/systemd
```

oder

```

#ln -sf /usr/lib/systemd/systemd /sbin/init

...

kernel /vmlinuz root=/dev/sda2 init=/sbin/init
```

das ist rihtig? oder nein?

----------

## uhai

Ich bin nach dem Wiki vorgegangen. Dort taucht ein entfernen von openrc nicht auf. Außerdem habe ich USE=systemd für dbus gesetzt:

```
 eix openrc

[I] app-admin/openrc-settingsd

     Available versions:  (~)1.0.1 {systemd}

     Installed versions:  1.0.1(19:25:55 10/07/13)(systemd)

     Homepage:            http://gnome.gentoo.org/openrc-settingsd.xml

     Description:         System settings D-Bus service for OpenRC

[I] sys-apps/openrc

     Available versions:  0.11.8 (~)0.12 (~)0.12.1 **9999 {debug ncurses +netifrc newnet pam prefix selinux static-libs tools unicode ELIBC="glibc" KERNEL="FreeBSD linux"}

     Installed versions:  0.12.1(14:31:55 10/06/13)(ncurses netifrc pam unicode -debug -newnet -prefix -selinux -static-libs -tools ELIBC="glibc" KERNEL="linux -FreeBSD")

     Homepage:            http://www.gentoo.org/proj/en/base/openrc/

     Description:         OpenRC manages the services, startup and shutdown of a host

```

Das würde es sicher nicht geben, wenn sich die beiden nicht vertragen würden, oder?

Meine grub.conf sieht so aus:

```
title Gentoo 3.7.10

root(hd0,0)

kernel /boot/kernel-3.10.7-gentoo-r1 root=/dev/sda3 rootfstype=ext4 real_init=/usr/lib/systemd/systemd

```

(kein lvm2, kein initramfs) Das sollte doch stimmen, oder?

Und schlußendlich sagt der Bug hier dioch klar aus, dass man openrc wg. function.sh zumindest vorerst behalten soll. Oder habe ich das falsch verstanden?

```

systemctl --no-reload --full --all

Running in chroot, ignoring request.
```

Habe ich das auch falsch verstanden?

Nach dem booten (von /dev/sda3) sagt systemctl, dass er keinen Connect zu dbus bekommt. Starte ich dbus aber über die init-Skripte (/etc/init.d/dbus start) bekomme ich den Fehler, das dbus schon laufe. Wenn dbus läuft, sieht man dem Prozess doch nicht an, wie er gestartet wurde? Dann müßte systemctl den doch auch finden....

uhai

----------

## syn0ptik

 *Quote:*   

> Ich bin nach dem Wiki vorgegangen. Dort taucht ein entfernen von openrc nicht auf. Außerdem habe ich USE=systemd für dbus gesetzt: 

 

Du muss entfernen dem sysvinit anstatt openrc.

Ich habe installiert die openrc, aber nicht app-admin/openrc-settingsd.

Und Ich gemcht das symlink auf /lib/systemd/systemd von /sbin/init. Und Ich habe anderen probleime mit systemd nachdem neustart.

----------

## Josef.95

 *Quote:*   

> Ich bin immer noch am Neu-Aufsetzen meines Systems. Nach dem reboot bemängelt systemctl das nicht laufende udev. mit /etc/init.d/udev start erhalte ich aber die Meldung, udev liefe schon. Anscheinend erkennt systemctl das laufende udev nicht. [....]

 

Klingt ein wenig danach als wenn du nur im emergency mode landest? Wenn ja, dann gibt es sicherlich schon weiter vorher beim booten Fehler. Normal ist systemd hier sehr gesprächig.

Schau auch mal ob im http://freedesktop.org/wiki/Software/systemd/Debugging/ was hilfreiches bei ist.

Und vergiss /etc/init.d/ Das sind StartScripte die normal mit OpenRC genutzt werden, die werden so ohne weiteres idR mit systemd nicht nutzbar sein.

Und ohne initrd mache in der kernel Zeile aus dem "real_init=..." besser ein init=...

----------

## syn0ptik

Josef.95, 

hallo

 *Quote:*   

> 
> 
> Und vergiss /etc/init.d/ Das sind StartScripte die normal mit OpenRC genutzt werden, die werden so ohne weiteres idR mit systemd nicht nutzbar sein. 

 

aber auf die wiki http://gentoo-en.vfose.ru/wiki/Systemd

 *Quote:*   

> systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts.

 

Das wissens gibt uns was ist möglich systemd gebraucht mit sysv scripts oder nein?

Oder Ich muss machen systemd .system datei mit:

```
ExecStart="/sbin/service systemstart start"
```

----------

## uhai

 *Quote:*   

> Should the system boot using openrc, try using real_init instead of init

  -> habe ich im Wiki gefunden. Soll man setzen, wenn openrc um starten verwendet wird. Da ich udev mit "/etc/init.d/udev" starten konnte (bzw. als gestartet erkannt wurde) dachte ich, der Startvorgang liefe nnoch mit openrc, also real_init=...  

War aber nichts.

SynOptik hatte recht, ich habe den Symlink gesetzt und jetzt startet systemd bis zum display-manager.service. Dort hängt er allerdings ohne Kommentar.  :Rolling Eyes: 

Josef.95 hat auch recht, das Ding geht in den emergency mode (wenn es überhaupt geht, also ohne display-manager.service). Was ihm allerdings fehlt, habe ich nnoch nicht herausgefunden. Ich hatte nur Fehler bei clamscan, freshclam, metalog und ähnlichen Diensten gesehen. Das log-file ist vermutlich /var/log/journal/lange_Nummer/system.journal. Und das scheint binär zu sein.... Da metalog nicht startet habe ich wenig Infos anzubieten...

Das erklärt vermutlich den Fehlstart von display-manager.service:

```

[    12.248] (II) LoadModule: "glx"

[    12.313] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so

[    13.873] (II) Module glx: vendor="NVIDIA Corporation"

[    13.873]    compiled for 4.0.2, module version = 1.0.0

[    13.873]    Module class: X.Org Server Extension

[    13.873] (II) NVIDIA GLX Module  319.49  Tue Aug 13 19:53:22 PDT 2013

[    13.882] Loading extension GLX

[    13.882] (==) Matched nouveau as autoconfigured driver 0

[    13.882] (==) Matched nv as autoconfigured driver 1

[    13.882] (==) Matched nouveau as autoconfigured driver 2

[    13.882] (==) Matched nv as autoconfigured driver 3

[    13.882] (==) Matched vesa as autoconfigured driver 4

[    13.882] (==) Matched modesetting as autoconfigured driver 5

[    13.882] (==) Matched fbdev as autoconfigured driver 6

[    13.882] (==) Assigned the driver to the xf86ConfigLayout

[    13.882] (II) LoadModule: "nouveau"

[    13.961] (WW) Warning, couldn't open module nouveau

[    13.961] (II) UnloadModule: "nouveau"

[    13.961] (II) Unloading nouveau

[    13.961] (EE) Failed to load module "nouveau" (module does not exist, 0)

[    13.961] (II) LoadModule: "nv"

[    13.961] (WW) Warning, couldn't open module nv

[    13.961] (II) UnloadModule: "nv"

[    13.961] (II) Unloading nv

[    13.961] (EE) Failed to load module "nv" (module does not exist, 0)

[    13.961] (II) LoadModule: "vesa"

[    13.961] (WW) Warning, couldn't open module vesa

[    13.961] (II) UnloadModule: "vesa"

[    13.961] (II) Unloading vesa

[    13.961] (EE) Failed to load module "vesa" (module does not exist, 0)

[    13.961] (II) LoadModule: "modesetting"

[    13.961] (WW) Warning, couldn't open module modesetting

[    13.961] (II) UnloadModule: "modesetting"

[    13.961] (II) Unloading modesetting

[    13.961] (EE) Failed to load module "modesetting" (module does not exist, 0)

[    13.961] (II) LoadModule: "fbdev"

[    13.961] (WW) Warning, couldn't open module fbdev

[    13.961] (II) UnloadModule: "fbdev"

[    13.961] (II) Unloading fbdev

[    13.961] (EE) Failed to load module "fbdev" (module does not exist, 0)

[    13.961] (EE) No drivers available.

[    13.961] (EE)

Fatal server error:

[    13.961] (EE) no screens found(EE)

[    13.961] (EE)

```

uhai

----------

## mv

 *uhai wrote:*   

> Da metalog nicht startet habe ich wenig Infos anzubieten...

 

journalctl -x

systemctl status

----------

## uhai

Danke mv für den Tip, das sieht hier so aus:

```
(chroot) livecd / # journalctl -x

-- Logs begin at (null), end at (null). --

Oct 09 12:53:17 tux systemd-journal[83]: Runtime journal is using 2.7M (max 802.5M, leaving 1.1G of free 7.8G, curren

Oct 09 12:53:17 tux systemd-journal[83]: Runtime journal is using 2.7M (max 802.5M, leaving 1.1G of free 7.8G, curren

Oct 09 12:53:17 tux kernel: Initializing cgroup subsys cpuset

Oct 09 12:53:17 tux kernel: Initializing cgroup subsys cpu

Oct 09 12:53:17 tux kernel: Initializing cgroup subsys cpuacct

Oct 09 12:53:17 tux kernel: Linux version 3.10.7-gentoo-r1y (root@livecd) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.3, p

Oct 09 12:53:17 tux kernel: Command line: root=/dev/sda3 rootfstype=ext4 real_init=/usr/lib/systemd/systemd

Oct 09 12:53:17 tux kernel: e820: BIOS-provided physical RAM map:

Oct 09 12:53:17 tux kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ebff] usable

Oct 09 12:53:17 tux kernel: BIOS-e820: [mem 0x000000000009ec00-0x000000000009ffff] reserved

Oct 09 12:53:17 tux kernel: BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved

Oct 09 12:53:17 tux kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000cfe8ffff] usable

Oct 09 12:53:17 tux kernel: BIOS-e820: [mem 0x00000000cfe90000-0x00000000cfea7fff] ACPI data

Oct 09 12:53:17 tux kernel: BIOS-e820: [mem 0x00000000cfea8000-0x00000000cfecffff] ACPI NVS

Oct 09 12:53:17 tux kernel: BIOS-e820: [mem 0x00000000cfed0000-0x00000000cfefffff] reserved

Oct 09 12:53:17 tux kernel: BIOS-e820: [mem 0x00000000ff700000-0x00000000ffffffff] reserved

Oct 09 12:53:17 tux kernel: BIOS-e820: [mem 0x0000000100000000-0x000000042fffffff] usable

Oct 09 12:53:17 tux kernel: NX (Execute Disable) protection: active

Oct 09 12:53:17 tux kernel: SMBIOS 2.5 present.

Oct 09 12:53:17 tux kernel: DMI: System manufacturer System Product Name/M4A785TD-M EVO, BIOS 2104    08/13/2010

Oct 09 12:53:17 tux kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved

Oct 09 12:53:17 tux kernel: e820: remove [mem 0x000a0000-0x000fffff] usable

Oct 09 12:53:17 tux kernel: No AGP bridge found

Oct 09 12:53:17 tux kernel: e820: last_pfn = 0x430000 max_arch_pfn = 0x400000000

Oct 09 12:53:17 tux kernel: MTRR default type: uncachable

Oct 09 12:53:17 tux kernel: MTRR fixed ranges enabled:

Oct 09 12:53:17 tux kernel:   00000-9FFFF write-back

Oct 09 12:53:17 tux kernel:   A0000-EFFFF uncachable

Oct 09 12:53:17 tux kernel:   F0000-FFFFF write-protect

Oct 09 12:53:17 tux kernel: MTRR variable ranges enabled:

Oct 09 12:53:17 tux kernel:   0 base 000000000000 mask FFFF80000000 write-back

Oct 09 12:53:17 tux kernel:   1 base 000080000000 mask FFFFC0000000 write-back

Oct 09 12:53:17 tux kernel:   2 base 0000C0000000 mask FFFFF0000000 write-back

Oct 09 12:53:17 tux kernel:   3 disabled

Oct 09 12:53:17 tux kernel:   4 disabled

Oct 09 12:53:17 tux kernel:   5 disabled

Oct 09 12:53:17 tux kernel:   6 disabled

Oct 09 12:53:17 tux kernel:   7 disabled

Oct 09 12:53:17 tux kernel: TOM2: 0000000430000000 aka 17152M

Oct 09 12:53:17 tux kernel: x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106

Oct 09 12:53:17 tux kernel: e820: update [mem 0xd0000000-0xffffffff] usable ==> reserved

Oct 09 12:53:17 tux kernel: e820: last_pfn = 0xcfe90 max_arch_pfn = 0x400000000

Oct 09 12:53:17 tux kernel: found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [ffff8800000ff780]

Oct 09 12:53:17 tux kernel: Scanning 1 areas for low memory corruption

Oct 09 12:53:17 tux kernel: Base memory trampoline at [ffff880000098000] 98000 size 24576

Oct 09 12:53:17 tux kernel: Using GB pages for direct mapping

Oct 09 12:53:17 tux kernel: init_memory_mapping: [mem 0x00000000-0x000fffff]

Oct 09 12:53:17 tux kernel:  [mem 0x00000000-0x000fffff] page 4k

Oct 09 12:53:17 tux kernel: BRK [0x01ebf000, 0x01ebffff] PGTABLE

Oct 09 12:53:17 tux kernel: BRK [0x01ec0000, 0x01ec0fff] PGTABLE

Oct 09 12:53:17 tux kernel: BRK [0x01ec1000, 0x01ec1fff] PGTABLE

...skipping...                                                                                                                            

Oct 10 04:41:41 tux systemd[1]: Starting Spamassassin daemon...

-- Subject: Unit spamassassin.service has begun with start-up

-- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

--

-- Unit spamassassin.service has begun starting up.

Oct 10 04:41:41 tux spamd[676]: perl: warning: Setting locale failed.

Oct 10 04:41:41 tux spamd[676]: perl: warning: Please check that your locale settings:

Oct 10 04:41:41 tux spamd[676]: LANGUAGE = (unset),

Oct 10 04:41:41 tux spamd[676]: LC_ALL = (unset),

Oct 10 04:41:41 tux spamd[676]: LANG = "de"

Oct 10 04:41:41 tux spamd[676]: are supported and installed on your system.

Oct 10 04:41:41 tux spamd[676]: perl: warning: Falling back to the standard locale ("C").

Oct 10 04:41:41 tux spamd[676]: logger: removing stderr method

Oct 10 04:41:41 tux spamd[678]: config: no rules were found! Do you need to run 'sa-update'?

Oct 10 04:41:42 tux spamd[676]: child process [678] exited or timed out without signaling production of a PID file: e

Oct 10 04:41:42 tux spamd[676]: child process [678] exited or timed out without signaling production of a PID file: e

Oct 10 04:41:42 tux systemd[1]: spamassassin.service: control process exited, code=exited status=255

Oct 10 04:41:42 tux systemd[1]: Failed to start Spamassassin daemon.

-- Subject: Unit spamassassin.service has failed

-- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

-- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/be02cf6855d2428ba40df7e9d022f03d

--

-- Unit spamassassin.service has failed.

--

-- The result is failed.

Oct 10 04:41:42 tux systemd[1]: Unit spamassassin.service entered failed state.

Oct 10 04:41:42 tux systemd[1]: spamassassin.service holdoff time over, scheduling restart.

Oct 10 04:41:42 tux systemd[1]: Stopping Spamassassin daemon...

-- Subject: Unit spamassassin.service has begun shutting down

-- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

--

-- Unit spamassassin.service has begun shutting down.

Oct 10 04:41:42 tux systemd[1]: Starting Spamassassin daemon...

-- Subject: Unit spamassassin.service has begun with start-up

-- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

--

-- Unit spamassassin.service has begun starting up.

Oct 10 04:41:42 tux systemd[1]: spamassassin.service start request repeated too quickly, refusing to start.

Oct 10 04:41:42 tux systemd[1]: Failed to start Spamassassin daemon.

-- Subject: Unit spamassassin.service has failed

-- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

-- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/be02cf6855d2428ba40df7e9d022f03d

--

-- Unit spamassassin.service has failed.

--

-- The result is failed.

Oct 10 04:41:42 tux systemd[1]: Unit spamassassin.service entered failed state.

```

Und noch ein Danke an Josef.95, der Link zu den Debugging-Tips ist auch hilfreich, das werde ich mir auch noch in Ruhe einpfeifen, sieht sehr gut aus... Eventuell fehlt mir eine Kernel-Option. Das prüfe ich noch.

uhai

----------

## syn0ptik

 *Quote:*   

> SynOptik hatte recht, ich habe den Symlink gesetzt und jetzt startet systemd bis zum display-manager.service. Dort hängt er allerdings ohne Kommentar. 
> 
> 

 

Zergute, aber mein systeme kein arbeit mit systemd.

nachdem anspringen den systemd:

```
Failed to create root cgroup hierarchy: Invalig argument

Failed to allocate manager object: Invalid argument 
```

Ich wird nur sehen das meldung, kein bringt bash.

Für mich Ich hatte service freigegeben:

```
# systemctl -a list-unit-files | grep enabled

dbus-org.freedesktop.NetworkManager.service enabled 

debug-shell.service                         enabled 

display-manager.service                     enabled 

gdm.service                                 enabled 

getty@.service                              enabled 

NetworkManager.service                      enabled 

remote-fs.target                            enabled 

```

 *Quote:*   

> Das erklärt vermutlich den Fehlstart von display-manager.service: 

 

Du kein installiert xorg-drivers auf emerge.

----------

## mv

 *uhai wrote:*   

> Danke mv für den Tip, das sieht hier so aus:

 

Du hast natürlich nur einen kleinen Teil des Log-Files gepostet...

I.W. siehst Du in diesem Teil einen der konzeptionellen Bugs (Poettering und seine Anhänger nennen es "tolles Feature") von systemd:

Der spamassassin-Daemon stirbt aus irgendeinem Grund bei Dir sofort (Bug oder Fehlkonfiguration, das musst Du irgendwann mal getrennt untersuchen); statt wie andere init-systeme, den spamassassin tot zu lassen, versucht systemd einfach immer und immer wieder ihn zu starten, bis es irgendwann wegen zu vieler Fehlstarts dann doch eine Pause mit Neustarts einlegt.

Zunächst mal solltest Du also den spamassassin.service (oder was auch immer spamassasin startet) bei Dir maskieren und erst wenn Du ihn repariert hast wieder zulassen.

(Möglicherweise stirbt der spamassassin-Daemon, weil eine Abhängigkeit fehlt, etwa weil er versucht, sich an ein Netz zu hängen, das noch nicht da ist).

----------

## Josef.95

uhai,

ich verstehe ehrlich gesagt noch nicht ganz was du eigentlich vorhast. Noch mal nachgefragt, versuchst du diese Init-Dienste wirklich in einer chroot Umgebung zu starten, oder auf einem real mit systemd gebootet System?

----------

## uhai

@Josef.95:

Eigentlich will ich meine Kiste nach dem Flop mit lvm2 jetzt ohne wieder laufen lassen. Meine Datensicherung war fehlerhaft, daher habe ich mich zur Neuinstallation entschlossen. Da systemd wohl auf Dauer nicht zu vermeiden sein wird und die angepeilten Features eigentlich eine Verbesserung wären, wollte ich das ausprobieren (das Probieren läuft doch auch gut, oder?   :Wink:  ). Für die Neuinstallation mache ich den chroot wie im Handbuch. Aber den Boot-Prozess im chroot zu "debuggen" ist deutlich schwieriger als mit SysVinit....

Grundsätzlich soll meine Kiste mit systemd starten und laufen....

@mv:

Ich deaktiviere diese Dienste vorerst. Wenn der Boot läuft, kümmere ich mich darum.

@SynOptik:

"emerge nvidia-drivers" sollte doch ausreichen, oder? Mich wundert nur, dass er nv und nouveau sucht... Das muss ich noch überprüfen.

Deine fehlermeldungen sagen mir gar nichts, aber schau dir das mal an:  http://freedesktop.org/wiki/Software/systemd/Debugging/ - mir hat es geholfen.

Mein Kernel hat nur eine der Fanotifys enthalten. Mal sehen, ob dbus jetzt besser anspricht  :Smile: 

uhai

----------

## uhai

journalctl-Auszug:

```
Your BIOS doesn't leave a aperture memory hole

Oct 09 12:53:17 tux kernel: Please enable the IOMMU option in the BIOS setup
```

IOMMU kennt mein Bios nicht, kann das auch irgendwie anders heißen?

Das hier scheint ein Problem zu sein:

```
Oct 09 12:53:17 tux kernel: usb 1-6.3: new high-speed USB device number 6 using ehci-pci       

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 1            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 2            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 3            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 4            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 5            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 6            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 7            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 8            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 9            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 10           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 11           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 12           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 13           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 14           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 15           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 16           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 17           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 18           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 19           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 20           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 21           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 22           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 23           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 24           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 25           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 26           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 27           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 28           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 29           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 30           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 31           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: devpath 6.3 ep0in 3strikes                  

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 1            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 2            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 3            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 4            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 5            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 6            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 7            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 8            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 9            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 10           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 11           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 12           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 13           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 14           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 15           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 16           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 17           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 18           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 19           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 20           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 21           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 22           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 23           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 24           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 25           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 26           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 27           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 28           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 29           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 30           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 31           

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: devpath 6.3 ep0in 3strikes                  

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 1            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 2            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 3            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 4            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 5            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 6            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 7            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 8            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 9            

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 10

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 11

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 12

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 13

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 14

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 15

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 16

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 17

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 18

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 19

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 20

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 21

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 22

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 23

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 24

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 25

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 26

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 27

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 28

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 29

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 30

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: detected XactErr len 0/8 retry 31

Oct 09 12:53:17 tux kernel: ehci-pci 0000:00:12.2: devpath 6.3 ep0in 3strikes

Oct 09 12:53:17 tux kernel: usb 1-6.3: device descriptor read/64, error -71

```

Danach kommt dann irgendwann:

```
Oct 09 12:53:17 tux systemd[1]: Failed to load configuration for auditd.service: No such file or directory

Oct 09 12:53:17 tux systemd[1]: Failed to load configuration for plymouth-start.service: No such file or d

Oct 09 12:53:17 tux systemd[1]: Failed to load configuration for syslog.service: No such file or directory

Oct 09 12:53:17 tux systemd[1]: Failed to load configuration for syslog.target: No such file or directory 

Oct 09 12:53:17 tux systemd[1]: Failed to load configuration for display-manager.service: No such file or 
```

Nach dem Boot konnte ich allerdings auf einer anderen Konsole auf die fEstplatten zugreifen...?

Folgende services waren (unter anderen) inaktiv nach dem Start:

var-lock.mount

sys-kernel-config.mount

sys-fs....nnections.mount

proc-sys....nfmt_misc.mount

Mein System sitzt auf /dev/sda3, also nicht usb. der zugriff auf die Pfade müsste also beim Start ja funktionieren... Eventuell sind auch nnur die zwei USB-Hubs dafür verantwortlich - vgl. hier

Das finde ich auch irritierend:

```

Initial RAM disk start-up required INITRD_USEC microseconds.  
```

Ich habe keine initrd...?

Clamav vermisst seinen user... wie stelle ich den wieder her? emerge clamav reicht nicht... In /etc/shadow und gshadow  ist der user da. Warum habe ich dann die Fehlermeldung?

uhai

----------

## syn0ptik

 *Quote:*   

> @SynOptik:
> 
> "emerge nvidia-drivers" sollte doch ausreichen, oder? Mich wundert nur, dass er nv und nouveau sucht... Das muss ich noch überprüfen. 

 

du muß machen

emerge nvidia-drivers

oder einsetzen

```
VIDEO_CARDS="nv"
```

und emerge xorg-drivers

also wichtig:

```
INPUT_DEVICES="evdev keyboard mouse synaptics tslib void"
```

jemand weiß warum dem fehler geschehen mit systemd laufen systeme?

```
Failed to create root cgroup hierarchy: Invalig argument

Failed to allocate manager object: Invalid argument 
```

screenshot:

http://filepic.ru/1381547948

----------

## uhai

 *syn0ptik wrote:*   

>  *Quote:*   @SynOptik:
> 
> "emerge nvidia-drivers" sollte doch ausreichen, oder? Mich wundert nur, dass er nv und nouveau sucht... Das muss ich noch überprüfen.  
> 
> du muß machen
> ...

 

Das steht bei mir in /etc/portage/make.conf:

```
...INPUT_DEVICES="evdev wacom"

VIDEO_CARDS="nvidia"

```

Und das ist meine Grafikarte:

```
01:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1)

```

die hier allerdings nicht gelistet wird -> also wird die Karte doch von den aktuellen nvidiadrivers unterstützt!

bisher hat das gereicht....

 *Quote:*   

>  jemand weiß warum dem fehler geschehen mit systemd laufen systeme?
> 
> ```
> Failed to create root cgroup hierarchy: Invalig argument
> 
> ...

 

Spontan würde ich auf den Kernel tippen. Starte make menuconfig und dann ssuche mit "/" nach "cgroups". Vielleicht fehlt die da etwa...

uhai

----------

## Josef.95

 *Quote:*   

> "emerge nvidia-drivers" sollte doch ausreichen, oder? Mich wundert nur, dass er nv und nouveau sucht... Das muss ich noch überprüfen.

  Dann fehlt wahrscheinlich eine xorg.conf in der der nvidia Treiber gesetzt ist.

Ich verstehe aber immer noch nicht warum du das ganze in einer chroot Umgebung machst (auch X wird im chroot wahrscheinlich nicht so ohne weitere funktionieren)

Ich würde mich zunächst erst mal um einen für systemd passend gebauten Kernel kümmern, und dann zunächst dafür sorgen dass das Basissystem sauber fehlerfrei bootet.  Die weitere Einrichtung ist dann via ssh von einem anderen Rechner aus meist bequemer zu erledigen.

----------

## uhai

 *Quote:*   

> Ich verstehe aber immer noch nicht warum du das ganze in einer chroot Umgebung machst (auch X wird im chroot wahrscheinlich nicht so ohne weitere funktionieren)
> 
> Ich würde mich zunächst erst mal um einen für systemd passend gebauten Kernel kümmern, und dann zunächst dafür sorgen dass das Basissystem sauber fehlerfrei bootet.  Die weitere Einrichtung ist dann via ssh von einem anderen Rechner aus meist bequemer zu erledigen.

 

Genau, würde ich auch... nur fehlt mir der andere Rechner.

Ich habe die Installation der nvidia-Karte jetzt nach wiki überprüft und eine nvidia.conf ergänzt.

uhai

----------

## firefly

 *uhai wrote:*   

>  *Quote:*   Ich verstehe aber immer noch nicht warum du das ganze in einer chroot Umgebung machst (auch X wird im chroot wahrscheinlich nicht so ohne weitere funktionieren)
> 
> Ich würde mich zunächst erst mal um einen für systemd passend gebauten Kernel kümmern, und dann zunächst dafür sorgen dass das Basissystem sauber fehlerfrei bootet.  Die weitere Einrichtung ist dann via ssh von einem anderen Rechner aus meist bequemer zu erledigen. 
> 
> Genau, würde ich auch... nur fehlt mir der andere Rechner.
> ...

 

du brauchst keinen anderen Rechner, du kannst den rest auch von selben rechner machen, wenn das system erstmal sauber bootet...

Wie schon Josef.95 gesagt hat. Lass erst mal alles andere. Das wichtigste ist dafür zu sorgen, dass das System bootet.

----------

## uhai

oh, das wusste ich nicht. Ich such dafür mal eine Anleitung...

Mein Rechner bootet inzwischen, nur beim Einloggen mmeines Users kommt noch dieser Fehler:

"Call to lnusertemp failed (temporary directories full?) check your installation"

So sieht das im Protokoll aus:

```

Oct 09 12:53:20 tux systemd[1]: ConditionDirectoryNotEmpty=|/etc/tmpfiles.d failed for systemd-tmpfiles-setup.service.

Oct 09 12:53:20 tux systemd[1]: ConditionDirectoryNotEmpty=|/usr/local/lib/tmpfiles.d failed for systemd-tmpfiles-setup.service.

Oct 09 12:53:21 tux systemd[1]: systemd-tmpfiles-setup.service changed start -> failed

Oct 09 12:53:21 tux systemd[1]: Job systemd-tmpfiles-setup.service/start finished, result=failed

-- Subject: Unit systemd-tmpfiles-setup.service has failed

-- Unit systemd-tmpfiles-setup.service has failed.

-- The result is failed.

Oct 09 12:53:21 tux systemd[1]: Unit systemd-tmpfiles-setup.service entered failed state.

Oct 09 13:14:22 tux systemd[1]: ConditionPathExists=/etc/alsa/state-daemon.conf failed for alsa-state.service.

Oct 09 13:14:22 tux systemd[1]: Starting of alsa-state.service requested but condition failed. Ignoring.

Oct 09 13:14:22 tux systemd[1]: ConditionDirectoryNotEmpty=|/etc/tmpfiles.d failed for systemd-tmpfiles-clean.service.

Oct 09 13:14:22 tux systemd[1]: ConditionDirectoryNotEmpty=|/usr/local/lib/tmpfiles.d failed for systemd-tmpfiles-clean.service.

Oct 09 13:14:31 tux systemd[1]: systemd-tmpfiles-clean.service changed start -> failed

Oct 09 13:14:31 tux systemd[1]: Job systemd-tmpfiles-clean.service/start finished, result=failed

-- Subject: Unit systemd-tmpfiles-clean.service has failed

-- Unit systemd-tmpfiles-clean.service has failed.

-- The result is failed.

Oct 09 13:14:31 tux systemd[1]: Unit systemd-tmpfiles-clean.service entered failed state.

Oct 09 13:39:30 tux systemd[1]: systemd-tmpfiles-setup.service changed dead -> failed

Oct 09 13:39:30 tux systemd[1]: systemd-tmpfiles-clean.service changed dead -> failed

Oct 09 13:39:51 tux systemd[1]: systemd-tmpfiles-setup.service changed dead -> failed

Oct 09 13:39:51 tux systemd[1]: systemd-tmpfiles-clean.service changed dead -> failed

Oct 09 13:40:07 tux systemd[1]: systemd-tmpfiles-setup.service changed dead -> failed

Oct 09 13:40:07 tux systemd[1]: systemd-tmpfiles-clean.service changed dead -> failed

Oct 09 13:40:23 tux systemd[1]: systemd-tmpfiles-setup.service changed dead -> failed

Oct 09 13:40:23 tux systemd[1]: systemd-tmpfiles-clean.service changed dead -> failed

Oct 09 13:40:45 tux systemd[1]: systemd-tmpfiles-setup.service changed dead -> failed

Oct 09 13:40:45 tux systemd[1]: systemd-tmpfiles-clean.service changed dead -> failed

Oct 09 13:40:56 tux systemd[1]: systemd-tmpfiles-setup.service changed dead -> failed

Oct 09 13:40:56 tux systemd[1]: systemd-tmpfiles-clean.service changed dead -> failed

Oct 09 13:41:30 tux systemd[1]: systemd-tmpfiles-setup.service changed dead -> failed

Oct 09 13:41:30 tux systemd[1]: systemd-tmpfiles-clean.service changed dead -> failed

Oct 09 13:41:39 tux systemd[1]: systemd-tmpfiles-setup.service changed dead -> failed

Oct 09 13:41:39 tux systemd[1]: systemd-tmpfiles-clean.service changed dead -> failed

....
```

uhai

----------

## uhai

Rechner läuft...

War ein Rechte -Problem meines Homes nachdem ich den unser neu angelegt hatte.

Die Bildschirmauflösung muss ich noch korrigieren und die locale erkennt KDE nicht richtig. Das sollte allerdings kein Problem mehr sein.

uhai

PS: Die Gruppenzuordnung meines users fehlen.... Welche Gruppen sind denn Standard?

Alles andere läuft jetzt.

Beim boot-Vorgang ist die ERkennung der USB_Geräte sehr sehr seeeehr langsam... Woran kann das liegen?

uhai

----------

