Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
systemd & udev in chroot-Umgebung
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German)
View previous topic :: View next topic  
Author Message
uhai
Veteran
Veteran


Joined: 23 Aug 2007
Posts: 1358
Location: Eppingen, Germany

PostPosted: Mon Oct 07, 2013 8:48 am    Post subject: systemd & udev in chroot-Umgebung Reply with 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. Die udev-Regeln (/etc/udev/rules.d/ habe ich bereits entfernt.

Code:

 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


Code:
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
Back to top
View user's profile Send private message
uhai
Veteran
Veteran


Joined: 23 Aug 2007
Posts: 1358
Location: Eppingen, Germany

PostPosted: Mon Oct 07, 2013 8:27 pm    Post subject: Re: systemd & udev in chroot-Umgebung Reply with quote

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.

Code:

 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


Code:
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

Nach dem Reboot habe ich keinen dbus laufen, daher funktioniert systemctl nicht. dbus kann ich nicht aktivieren... Welche Angaben braucht Ihr?
Back to top
View user's profile Send private message
syn0ptik
Apprentice
Apprentice


Joined: 09 Jan 2013
Posts: 267

PostPosted: Mon Oct 07, 2013 10:40 pm    Post subject: Reply with quote

hallo,
Du müss anschließen systemd mit init systeme.
Code:
ln -s /usr/lib/systemd/systemd /sbin/init


Können du antworten hier ob anfangt das systeme arbeit?
Back to top
View user's profile Send private message
uhai
Veteran
Veteran


Joined: 23 Aug 2007
Posts: 1358
Location: Eppingen, Germany

PostPosted: Tue Oct 08, 2013 6:08 am    Post subject: Reply with quote

Code:
(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.??
Back to top
View user's profile Send private message
syn0ptik
Apprentice
Apprentice


Joined: 09 Jan 2013
Posts: 267

PostPosted: Tue Oct 08, 2013 7:08 am    Post subject: Reply with quote

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

Und reboot die rechner mit das systeme root.
Back to top
View user's profile Send private message
franzf
Advocate
Advocate


Joined: 29 Mar 2005
Posts: 4565

PostPosted: Tue Oct 08, 2013 7:59 am    Post subject: Reply with quote

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

Und reboot die rechner mit das systeme root.

/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...)
Back to top
View user's profile Send private message
syn0ptik
Apprentice
Apprentice


Joined: 09 Jan 2013
Posts: 267

PostPosted: Tue Oct 08, 2013 9:21 am    Post subject: Reply with quote

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
Code:
kernel /vmlinuz root=/dev/sda2 init=/usr/lib/systemd/systemd

oder
Code:

#ln -sf /usr/lib/systemd/systemd /sbin/init
...
kernel /vmlinuz root=/dev/sda2 init=/sbin/init

das ist rihtig? oder nein?
Back to top
View user's profile Send private message
uhai
Veteran
Veteran


Joined: 23 Aug 2007
Posts: 1358
Location: Eppingen, Germany

PostPosted: Tue Oct 08, 2013 7:02 pm    Post subject: Reply with 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:
Code:
 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:
Code:
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?

Code:

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
Back to top
View user's profile Send private message
syn0ptik
Apprentice
Apprentice


Joined: 09 Jan 2013
Posts: 267

PostPosted: Wed Oct 09, 2013 5:05 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Josef.95
Advocate
Advocate


Joined: 03 Sep 2007
Posts: 4509
Location: Germany

PostPosted: Wed Oct 09, 2013 8:23 pm    Post subject: Reply with quote

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=...
Back to top
View user's profile Send private message
syn0ptik
Apprentice
Apprentice


Joined: 09 Jan 2013
Posts: 267

PostPosted: Thu Oct 10, 2013 1:18 am    Post subject: Reply with quote

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:
Code:
ExecStart="/sbin/service systemstart start"
Back to top
View user's profile Send private message
uhai
Veteran
Veteran


Joined: 23 Aug 2007
Posts: 1358
Location: Eppingen, Germany

PostPosted: Thu Oct 10, 2013 9:07 pm    Post subject: Reply with quote

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. :roll:

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:
Code:

[    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
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Thu Oct 10, 2013 9:21 pm    Post subject: Reply with quote

uhai wrote:
Da metalog nicht startet habe ich wenig Infos anzubieten...

journalctl -x
systemctl status
Back to top
View user's profile Send private message
uhai
Veteran
Veteran


Joined: 23 Aug 2007
Posts: 1358
Location: Eppingen, Germany

PostPosted: Thu Oct 10, 2013 9:30 pm    Post subject: Reply with quote

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

Code:
(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
Back to top
View user's profile Send private message
syn0ptik
Apprentice
Apprentice


Joined: 09 Jan 2013
Posts: 267

PostPosted: Fri Oct 11, 2013 2:02 am    Post subject: Reply with quote

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. :roll:

Zergute, aber mein systeme kein arbeit mit systemd.
nachdem anspringen den systemd:
Code:
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:
Code:
# 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.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Fri Oct 11, 2013 3:10 am    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
Josef.95
Advocate
Advocate


Joined: 03 Sep 2007
Posts: 4509
Location: Germany

PostPosted: Fri Oct 11, 2013 3:24 am    Post subject: systemd & udev in chroot-Umgebung Reply with quote

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?
Back to top
View user's profile Send private message
uhai
Veteran
Veteran


Joined: 23 Aug 2007
Posts: 1358
Location: Eppingen, Germany

PostPosted: Fri Oct 11, 2013 4:55 am    Post subject: Reply with quote

@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 :-)

uhai
Back to top
View user's profile Send private message
uhai
Veteran
Veteran


Joined: 23 Aug 2007
Posts: 1358
Location: Eppingen, Germany

PostPosted: Fri Oct 11, 2013 4:35 pm    Post subject: Reply with quote

journalctl-Auszug:
Code:
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:
Code:
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:
Code:
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:

Code:

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
Back to top
View user's profile Send private message
syn0ptik
Apprentice
Apprentice


Joined: 09 Jan 2013
Posts: 267

PostPosted: Sat Oct 12, 2013 3:05 am    Post subject: Reply with quote

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
Code:
VIDEO_CARDS="nv"

und emerge xorg-drivers
also wichtig:
Code:
INPUT_DEVICES="evdev keyboard mouse synaptics tslib void"


jemand weiß warum dem fehler geschehen mit systemd laufen systeme?
Code:
Failed to create root cgroup hierarchy: Invalig argument
Failed to allocate manager object: Invalid argument

screenshot:
http://filepic.ru/1381547948
Back to top
View user's profile Send private message
uhai
Veteran
Veteran


Joined: 23 Aug 2007
Posts: 1358
Location: Eppingen, Germany

PostPosted: Sat Oct 12, 2013 5:53 am    Post subject: Reply with quote

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
emerge nvidia-drivers
oder einsetzen
Code:
VIDEO_CARDS="nv"

und emerge xorg-drivers
also wichtig:
Code:
INPUT_DEVICES="evdev keyboard mouse synaptics tslib void"


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

Code:
...INPUT_DEVICES="evdev wacom"
VIDEO_CARDS="nvidia"

Und das ist meine Grafikarte:
Code:
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?
Code:
Failed to create root cgroup hierarchy: Invalig argument
Failed to allocate manager object: Invalid argument

screenshot:
http://filepic.ru/1381547948


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

uhai
Back to top
View user's profile Send private message
Josef.95
Advocate
Advocate


Joined: 03 Sep 2007
Posts: 4509
Location: Germany

PostPosted: Sun Oct 13, 2013 12:49 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
uhai
Veteran
Veteran


Joined: 23 Aug 2007
Posts: 1358
Location: Eppingen, Germany

PostPosted: Sun Oct 13, 2013 5:55 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
firefly
Watchman
Watchman


Joined: 31 Oct 2002
Posts: 5161

PostPosted: Sun Oct 13, 2013 7:54 am    Post subject: Reply with quote

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.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn.
Back to top
View user's profile Send private message
uhai
Veteran
Veteran


Joined: 23 Aug 2007
Posts: 1358
Location: Eppingen, Germany

PostPosted: Sun Oct 13, 2013 10:55 am    Post subject: Reply with quote

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:
Code:

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
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum