• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] Apparmor - sporadische Aussetzer

revealed

Guru
Problem besteht mit SuSE 10.3 nicht mehr!

Hi :)

Also bei mir funktioniert seit einer ganzen Weile apparmor nicht ganz sauber.
Das heisst, beim einen Bootvorgang kommt apparmor failed.

Beim nächsten dann kommt wieder apparmor - done.

Apparmor failed kommt meistens bei einem Warmneustart von Windows in Linux. Bei einem Hardoff und anschliessendem erneutem Hochfahren klappt es wieder mit Apparmor.

Weiter ist mir aufgefallen, dass manchmal beim Herunterfahren von Linux 2x Shutting down Apparmor done kommt.
Also die "failed" meldung kommt meistens nur beim hochfahren.

Und was für ein PC ist das werdet ihr jetzt fragen:
openSUSE 10.2; 2.6.18.8-0.1-default i386 GNU/Linux;
Was mit Hardwaremäßig im Zusammenhang auffällt, es ist ein Core2 Duo E6600 der hat irgendwas integriert, was mit DEP zu tun hat? Könnte das mit im Spiel sein?

Verwende folgendes Apparmor:
Code:
rpm -qa |grep apparmor
apparmor-docs-2.0.1-6
libapparmor-2.0-35
apparmor-profiles-2.0.1-14
yast2-apparmor-2.0.1-11
apparmor-parser-2.0.1-11
apparmor-utils-2.0.1-8
An der Grundkonfiguration von Apparmor habe ich nichts wissentlich verändert.

laut Runleveleditor starten folgende Dienste:
"boot.apparmor" Runlevel B;2;3; und 5 (AppArmor initialzation)
"aaeventd" in Runlevel 2;3 und 5 (Apparmor Notification and Reporting daemon)

Ich glaube die failed Meldung gibt es meist im Zusammenhang mit "Apparmor Profiles".

Kann mir bitte jemand helfen, dem ganzen auf die Schliche zu kommen?

Würde mich sehr freuen, da ich diese Apparmor Aussetzer nicht nachvollziehen kann, jedoch nicht auf Apparmor verzichten möchte.

Ich reboote halt immer so oft, bis Apparmor - "done" ist.

Danke im Vorraus

Gruss

R
 
OP
revealed

revealed

Guru
Ok jetzt hab ich gerade wieder einen Warmstart aus Windows in Linux gemacht:

Logdatei mit Apparmor failed: (/var/log/boot.msg)
http://phpfi.com/225250

Danach hab ich den Rechner ausgeschaltet (komplett runtergefahren) anschließend 2 Minuten gewartet - also einen richtigen Hardoff -
Dann wieder hochgefahren und apparmor failed nicht:
Logdatei Apparmor not failed after Hard - off. /var/log/boot.msg
http://phpfi.com/225251

Wo ist der Haken? Hilft mir bitte jemand?

Und wenn ich aus Windows heraus eben diesen Warmstart mache, dann ist es:
Starting AppArmor Event daemon failed
Laut der Logdatei mit Apparmor failed.
Also aus der Logdatei mit failed:
grep App /apparmorfailbootlog.txt
<6>AppArmor: AppArmor initialized
<5>audit(1176174633.189:2): AppArmor initialized
Loading AppArmor module done
Loading AppArmor profiles done
Loading AppArmor profiles - AppArmor already loaded with profiles.skipped
Starting AppArmor Event daemon failed
Und aus der wo es nach einem Hardoff dann klappt:
grep App /apparmorNOfailbootlog.txt
<6>AppArmor: AppArmor initialized
<5>audit(1176175057.014:2): AppArmor initialized
Loading AppArmor module done
Loading AppArmor profiles done
<notice>Loading AppArmor profiles - AppArmor already loaded with profiles.skipped
Starting AppArmor Event daemon done

Help!

Gruss

R
 
OP
revealed

revealed

Guru
hmm konnte gerade etwas neues feststellen, also wenn die Apparmor mal wieder zickt, dann zickt sie gescheid, das hängt nichtmal nur vom Warmstart aus Windows in Linux ab.

Gerade beispielsweise, hab ich wieder ein neues Paket via Yast2 bezogen. Und im Anschluss nach einem Neustart des PC wollte Apparmor wieder nicht. Wenn es failed, failed es bei mehreren neustarts auch -

Aber wenn Apparmor nicht wollte, dann klappt es bis jetzt zum Glück immer, wenn ich bei dem Start mit "failed" direkt Apparmor neustarte, während der Rechner schon oben ist. Und dann im Anschluss starte ich den ganzen Rechner neu, dann klappt Apparmor wieder. Den neustart vom Dienst erledige ich über Yast2 Runleveleditor - wieder Speichern und dann eben wie erwähnt.

Ansonsten kommt (failed) immerwieder - wenn es kommt.

Kann das doch damit zu tun haben, an welcher Stelle oder in welcher Reihenfolge Apparmor beim hochfahren einsortiert wird?
--help!

Keiner eine Idee? Oder kann das Verhalten bestätigen`?

Gruss

R
 
OP
revealed

revealed

Guru
Ein weiterer Report:

Für mein Mainboard gab es ein BIOS Update!

"ASUS P5B"! --> "1202"
1. Fix system may sometimes hang after load default in setup then exiting
right away while having Conroe CPU installed.
2. Add new uCode to support new CPU.

Damit läuft es besser? Also seit gestern wo ich das eingespielt hatte, hatte ich bisher kein Apparmor failed mehr -

werde es weiter beobachten!

Außerdem failed mir der EHCI BIOS Hand Off anscheinend nicht mehr, wenn im BIOS Enabled:
Code:
grep ehci /var/log/boot.msg
<6>ehci_hcd 0000:00:1a.7: EHCI Host Controller
<6>ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
<6>ehci_hcd 0000:00:1a.7: debug port 1
<6>ehci_hcd 0000:00:1a.7: irq 233, io mem 0xffaffc00
<6>ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
<6>usb usb1: Manufacturer: Linux 2.6.18.8-0.1-default ehci_hcd
<6>ehci_hcd 0000:00:1d.7: EHCI Host Controller
<6>ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
<6>ehci_hcd 0000:00:1d.7: debug port 1
<6>ehci_hcd 0000:00:1d.7: irq 50, io mem 0xffaff800
<6>ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
<6>usb usb2: Manufacturer: Linux 2.6.18.8-0.1-default ehci_hcd
disk@wild-thing:~> grep EHCI /var/log/boot.msg
<6>ehci_hcd 0000:00:1a.7: EHCI Host Controller
<6>ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
<6>usb usb1: Product: EHCI Host Controller
<6>ehci_hcd 0000:00:1d.7: EHCI Host Controller
<6>ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
<6>usb usb2: Product: EHCI Host Controller

Auffällig ist aber immernoch das hier:
Code:
grep BIOS /var/log/boot.msg
<6>BIOS-provided physical RAM map:
<4> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
<4> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
<4> BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
<4> BIOS-e820: 0000000000100000 - 000000007ff90000 (usable)
<4> BIOS-e820: 000000007ff90000 - 000000007ff9e000 (ACPI data)
<4> BIOS-e820: 000000007ff9e000 - 000000007ffe0000 (ACPI NVS)
<4> BIOS-e820: 000000007ffe0000 - 0000000080000000 (reserved)
<4> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
<4> BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
<3>PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved
<6>PCI: PCI BIOS revision 3.00 entry at 0xf0031, last bus=5
<6>PnPBIOS: Disabled by ACPI PNP
<6>apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
<6>BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
Von was auch immer das kommen mag -- ich meld mich wegen Apparmor nochmal -

Gruss

R
 
OP
revealed

revealed

Guru
Also wenn ich nur wüsste woran es liegt - ich komm einfach ned drauf!

Jetz liefs mal nen Tag lang... und gerade neugestartet und -- blopp:

disk@wild-thing:~> grep failed /var/log/boot.msg
<notice>startproc: execve (/usr/sbin/aa-eventd) [ /usr/sbin/aa-eventd -p /var/run/aa-eventd.pid ], [ CONSOLE=/dev/console ROOTFS_FSTYPE=ext3 SHELL=/bin/sh TERM=linux ROOTFS_FSCK=0 LC_ALL=POSIX INIT_VERSION=sysvinit-2.86 REDIRECT=/dev/tty1 COLUMNS=128 PATH=/bin:/sbin:/usr/bin:/usr/sbin vga=0x317 RUNLEVEL=5 PWD=/ SPLASHCFG= PREVLEVEL=N LINES=48 HOME=/ SHLVL=2 splash=0 SPLASH=no ROOTFS_BLKDEV=/dev/sdb6Verify the apropriate mtrr setting no valid memory size has been found!failed
Starting AppArmor Event daemon failed
disk@wild-thing:~> su
Passwort:
wild-thing:/home/disk # rca
rcaaeventd rcalsasound rcapparmor rcatieventsd rcautofs
rcacpid rcapache2 rcatd rcauditd
wild-thing:/home/disk # rcaaeventd restart
Shutting down AppArmor Event daemon done
Starting AppArmor Event daemon done
wild-thing:/home/disk # reboot

*zack --> reboot --> und läuft wieder ....*

gruss

R
 
Oben