So, heute kam das nächste Kernelupdate, diesmal mit Fehlermeldungen:
(3/6) upgrading kernel26                            [#####################] 100%
>>>
>>> If you use the LILO bootloader, you should run 'lilo' before rebooting.
>>>
>>> Updating module dependencies. Please wait ...
>>> MKINITCPIO SETUP
>>> ----------------
>>> If you use LVM2, Encrypted root or software RAID,
>>> Ensure you enable support in /etc/mkinitcpio.conf .
>>> More information about mkinitcpio setup can be found here:
>>> http://wiki.archlinux.org/index.php/Mkinitcpio

>>> Generating initial ramdisk, using mkinitcpio.  Please wait...
==> Building image "default"
==> Running command: /sbin/mkinitcpio -k 2.6.22-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img
:: Begin build
:: Parsing hook [base]
:: Parsing hook [udev]
:: Parsing hook [autodetect]
/lib/initcpio/install/autodetect: line 14: mdadm: command not found
:: Parsing hook [pata]
:: Parsing hook [scsi]
:: Parsing hook [sata]
:: Parsing hook [usbinput]
:: Parsing hook [keymap]
:: Parsing hook [filesystems]
:: Generating module dependencies
/sbin/mkinitcpio: line 226: depmod: command not found
ERROR: file '/tmp/lib/modules/2.6.22-ARCH/modules.dep' does not exist
ERROR: file '/tmp/lib/modules/2.6.22-ARCH/modules.alias' does not exist
ERROR: file '/tmp/lib/modules/2.6.22-ARCH/modules.symbols' does not exist
/sbin/mkinitcpio: line 235: gen_init_cpio: command not found
:: Generating image '/boot/kernel26.img'...SUCCESS
==> SUCCESS
==> Building image "fallback"
==> Running command: /sbin/mkinitcpio -k 2.6.22-ARCH -c /etc/mkinitcpio.d/kernel26-fallback.conf -g /boot/kernel26-fallback.img
:: Begin build
:: Parsing hook [base]
:: Parsing hook [udev]
:: Parsing hook [ide]
:: Parsing hook [pata]
:: Parsing hook [scsi]
:: Parsing hook [sata]
:: Parsing hook [usbinput]
:: Parsing hook [raid]
:: Parsing hook [filesystems]
:: Generating module dependencies
/sbin/mkinitcpio: line 226: depmod: command not found
ERROR: file '/tmp/lib/modules/2.6.22-ARCH/modules.dep' does not exist
ERROR: file '/tmp/lib/modules/2.6.22-ARCH/modules.alias' does not exist
ERROR: file '/tmp/lib/modules/2.6.22-ARCH/modules.symbols' does not exist
/sbin/mkinitcpio: line 235: gen_init_cpio: command not found
:: Generating image '/boot/kernel26-fallback.img'...SUCCESS
==> SUCCESS
Da man ja aus Erfahrungen lernt, habe ich danach mkinitcpio nochmal manuell aufgerufen.
[root@itchy man]# mkinitcpio -p kernel26 
==> Building image "default"
==> Running command: /sbin/mkinitcpio -k 2.6.22-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img
:: Begin build
:: Parsing hook [base]
:: Parsing hook [udev]
:: Parsing hook [autodetect]
:: Parsing hook [pata]
:: Parsing hook [scsi]
:: Parsing hook [sata]
:: Parsing hook [usbinput]
:: Parsing hook [keymap]
:: Parsing hook [filesystems]
:: Generating module dependencies
:: Generating image '/boot/kernel26.img'...SUCCESS
==> SUCCESS
==> Building image "fallback"
==> Running command: /sbin/mkinitcpio -k 2.6.22-ARCH -c /etc/mkinitcpio.d/kernel26-fallback.conf -g /boot/kernel26-fallback.img
:: Begin build
:: Parsing hook [base]
:: Parsing hook [udev]
:: Parsing hook [ide]
:: Parsing hook [pata]
:: Parsing hook [scsi]
:: Parsing hook [sata]
:: Parsing hook [usbinput]
:: Parsing hook [raid]
:: Parsing hook [filesystems]
:: Generating module dependencies
:: Generating image '/boot/kernel26-fallback.img'...SUCCESS
==> SUCCESS
Das lief sauber durch. WTF?
Hi,

hab soeben auch das Kernel-update gezogen. Und, es funktioiert natürlich.

Es ist aber schon merkwürdig was dir da so passiert. Obwohl, derzeit wohl irgendwie der Wurm drin, denn es haben ne menge Leute Probleme mit Kernelpanik. Ist mir bei Arch völlig fermd.

Ist natürlich schwer zu sagen an was es jetzt liegt - zumal es ja beim zweiten Mal geht - dazu weiß ich nicht wie du installiert und konfiguriert hast.
Es kann eigentlich nichts großes sein, sonst würde es garnicht gehen.

Das einzige was mir auffällt ist, dass du praktisch alle Hooks noch drin hast.
Bei mir sieht das so aus:
HOOKS="base udev autodetect sata filesystems"
Mein Boot-LW ist eine SATA-Platte, alles andere hab ich drausen.

Jean-Paul
Konfiguriert hab ich am Kernel selber eigentlich gar nichts, ist alles so, wie es installiert wurde. Klar kann ich ein paar Hooks rausnehmen, ich denke mal scsi und sata, da ich beide Arten von Laufwerken nicht nutze. Aber ich glaube nicht, dass das wesentlich was ausmacht, zumal es ja auch nur Symptomunterdrückung wäre, keine wirkliche Lösung. Es müsste ja auch mit den Hooks funktionieren.

Das einzige, was mir noch einfällt: Könnte es ein Nebenläufigkeitsproblem sein? Ich habe hier einen Dual-Core und habe auch irgendwo die Option aktiviert, das beim Bauen/Compilieren mehrere Kerne genutzt werden. Aber soweit ich das überblicke, spielt das hier wohl keine Rolle. Hab allerdings von den Arch-internen Prozessen und Scripten nicht so viel Ahnung.
Moin,

ich habe einen uralten Athlon XP und das gleiche Problem wie du.
Leider läuft der manuelle Aufruf auch nicht sauber durch 🙁

[root@arch sascha]# /sbin/mkinitcpio -p kernel26
==> Building image "default"
==> Running command: /sbin/mkinitcpio -k 2.6.22-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img
:: Begin build
:: Parsing hook [base]
:: Parsing hook [udev]
:: Parsing hook [autodetect]
/lib/initcpio/install/autodetect: line 14: mdadm: command not found
:: Parsing hook [pata]
:: Parsing hook [scsi]
:: Parsing hook [sata]
:: Parsing hook [usbinput]
:: Parsing hook [keymap]
:: Parsing hook [filesystems]
:: Generating module dependencies

Hab nen Report gemacht: http://bugs.archlinux.org/task/7833
/sbin/mkinitcpio: line 226: depmod: command not found
ERROR: file '/tmp/lib/modules/2.6.22-ARCH/modules.dep' does not exist
ERROR: file '/tmp/lib/modules/2.6.22-ARCH/modules.alias' does not exist
ERROR: file '/tmp/lib/modules/2.6.22-ARCH/modules.symbols' does not exist
:: Generating image '/boot/kernel26.img'.../sbin/mkinitcpio: line 235: gen_init_cpio: command not found
Die Fehlermeldungen sind ja bei euch beiden eindeutig, es werden zwei Programme
nicht gefunden die vom Kernel-Update vollkommen unabhängig sind.

Beide Programme befinden sich in /sbin.
Wenn ein Shell-Skript diese nicht findet bedeutet das entweder:
- es wird an der falschen Stelle gesucht (Aber in mkinitcpio gibt es keine Aufrufe
mit expliziter Pfadangabe)
- Der Pfad wo das Programm liegt ist nicht im $PATH des Users.
- Es fehlen Rechte(x) um in das Verzeichniss reinzusehen
- Das Programm ist wirklich nicht da

Was sagt denn bei euch:
which mdadm
which depmod

Beide programme auch mal mit Parameter -h aufrufen, die Tools sollten ihre Hilfe ausspucken.

Arbeitet ihr zufällig mit sudo oder schon explizit als root?
Gibt es bei dir Usul evtl. auch das Problem, dass du pacman -Syu über
ein "su" anstatt eines "su -" ausgeführt hast? Mit su fehlen wohl einige Sachen im Path, die dann nicht gefunden werden. Mit su - hat man ja die komplette Root-Umgebung und damit geht es dann auch sauber.
Das mit der anderen Umgebung könnte theoretisch sein, da ich das Kernel-Update über alunn gestartet habe. Wie alunn den Aufruf genau gestaltet, weiß ich jetzt nicht, kann erst heute Abend nachschauen.

Allerdings dürfte es nicht am su - liegen, da auch dem erfolgreichen zweiten Aufruf nur ein simples su vorangegangen ist. Aber vielleicht macht alunn ja was mit sudo und erst da tritt ein Unterschied auf.
Das dürfte euer beider Problem sein, daß /sbin nicht im Pfad eures Users steht der
entweder su bzw. sudo benutzt.

su ohne - oder -l benutzt das Enviroment des Users, ein wie immer auch geartetes
sudo pacman startet ja auch lediglich pacman mit Super-Rechten, benutzt aber das
Enviroment des Ausgangsusers.

Systemupdates sollte man schon explizit als root mit einer Login-Shell machen.
Es schadet aber auch nichts /sbin in den PATH des Hauptusers aufzunehmen, gerade
um solche Irritationen mit su zu vermeiden.
Das könnte die seltsamen Probleme, die einige in letzter Zeit hatten erklären. Es ist wohl keine schlechte Idee, das Problem dem Alunn-Maintainer zu melden.
Bevor wir jemanden auf die Füsse treten, können wir aber auch noch etwas selber grübeln, oder?

Als erstes würde mich mal interessieren, ob andere, die ebenfalls Probleme hatte, ähnliche "Umwege" zum Update gehen.

Zum anderen habe ich mal geschaut, was alunn eigentlich macht. Die kochen schließlich auch nur mit Wasser. Bei einem Update macht alunn erstmal folgendes:
su - -c alunn_updatescript
und in diesem Script steht dann:
#!/bin/bash
echo Running pacman -Syu:
pacman -Syu
echo
echo -n :: Press \[Enter\] to exit ::
read
Das sieht für mich alles ehrlich gesagt genauso aus, als wenn ich das Update manuell mache. Im Gegenteil, es macht sogar etwas besser (laut Tenor in diesem Thread), es startet su mit dem -, was ich manuell nicht mache. Das ist der einzige Unterschied, der mir noch auffällt. Und genau das sollte das Problem ja eigentlich beseitigen.

Ich könnte die Geschichte zwar an den alunn-Maintainer bzw. -Entwickler melden, aber ich wüßte ehrlich gesagt nicht, was ich ihm konkret anlasten könnte ... Ich kann schließlich nicht beweisen, dass es ohne alunn geht, da ich so ein Update schlecht komplett rückgängig machen kann. Theoretisch müsste man ein Backup vom System machen, mit alunn beim nächsten mal den Kernel updaten, Fehler protokollieren, dann Backup zurückspielen, Update nochmal ...
Tritt ihm auf die Füße 😉

Doch, in diesem Fall ist genau das Problem, das alaun eine Login Shell startet.

Test:
Mache dir ein Skript in /tmp/t.sh 
#!/bin/bash
#
id
echo $PATH
Mach das ausführbar, chmod +x /tmp/t.sh

Dann starte als Normaluser dieses Skript, so wie aluun das auch macht:
su - -c /tmp/t.sh
und achte auf die Ausgabe vom Path.
Zum Vergleich starte das mal mit:
su -c /tmp/t.sh

info su gibt die Erklärung: 
`--login'
     Make the shell a login shell.  This means the following.  Unset all
     environment variables except `TERM', `HOME', and `SHELL' (which
     are set as described above), and `USER' and `LOGNAME' (which are
     set, even for the super-user, as described above), and set `PATH'
                                                                           ^^^^^^^^^^^^^^^^
     to a compiled-in default value.  Change to USER's home directory.
^^^^^^^^^^^^^^^^^^^^
     Prepend `-' to the shell's name, intended to make it read its
     login startup file(s).
Der Fehler entsteht, daß durch -c keine Shell gestartet wird, also die $shell.rc bzw. profile
von /root nicht eingelesen wird.
Der Author müßte die relevaten Pfade im alunn_updatescript definieren.
Oder halt nicht als login-Shell starten.

Also beißen sich hier -login und -c
Wobei mich das momentan ein wenig wundert, da mir das in dieser Krassheit
noch nicht begegnet ist.

Ich habe das gerade mal auf einem Debian gestest, dort werden die .profiles eingelesen.
Allerdings habe ich dort noch coreutils 5.97

Jetzt erinnere ich mich aber, daß letzte Tage ein neues coreutils kam:
[2007-08-17 10:27] coreutils (6.9-1 -> 6.9-2) aktualisiert

Entweder kam diese in info su beschriebene Restriktion auf diesen fest
einkompilierten Pfad wesentlich nach der momentanen Debian-Version.

Oder beim upgedateten Arch coreutils hast sich ein Fehler eingeschlichen.
Was auch sein, kann, da du mit diesem aluun definitiv schon vorher den Fehler
gehabt haben müßtest (sobald Programme aus /sbin gebraucht wurden).

Ich habe gerade noch mal coreutils downgegraded, die letzte Version hatte das
gleiche Verhalten.
Man müßte im changelog also mal nachschauen, wann dieses Verhalten:
festeinkomilierter Path hinzugefügt wurde.
Evtl. hat der aluun Author das nicht mitbekommen.
Ja, gut.

Wobei beim Aufruf ohne -/-l (also ohne Login-Shell) ja dann das Enviroment des
aufrufenden Users mitgenommen wird. Und wenn der z.B. /sbin nicht im Pfad hat
dann würde ein Update bzgl des Kernels auch wieder in die Hose gehen.

Besser wäre es evtl. wenn im Hauptskript explizit die benötigten Pfade nochmal
gesetzt würden, also PATH=foo:bar
Dann könnte man auch mit dem (höchstwahrscheinlich sicherheitsbedingten)
"Feature" von su -l leben.
Es gibt eine neue Version von alunn, welche das Problem behebt. Ich markiere den Thread daher als gelöst.