nouveau upgrade failed
 

Nouveau upgrade path was broken for me. It printed out to the screen
something like "module 'nouveau' not found" while building the new initrd.
It's not in the pacman.log.


I'm using early kms mode. This probably happens because the new nouveau
module is not yet present when the kernel is updated and new initrd is
built.


Maybe we should start to rebuild the initrd from nouveau post.update
because we recommend early kms mode anyway whenever possible?


After reboot kms wasn't enabled. I did pacman -S kernel26 again and this
time it picked up the module into the initrd.


-Andy

[2009-12-07 05:47] upgraded kernel26-firmware (2.6.31-1 -> 2.6.32-1)
[2009-12-07 05:47] >>> Updating module dependencies. Please wait ...
[2009-12-07 05:47] >>> MKINITCPIO SETUP
[2009-12-07 05:47] >>> ----------------
[2009-12-07 05:47] >>> If you use LVM2, Encrypted root or software RAID,
[2009-12-07 05:47] >>> Ensure you enable support in /etc/mkinitcpio.conf .
[2009-12-07 05:47] >>> More information about mkinitcpio setup can be
found here:

[2009-12-07 05:47] >>> http://wiki.archlinux.org/index.php/Mkinitcpio
[2009-12-07 05:47]
[2009-12-07 05:47] >>> Generating initial ramdisk, using mkinitcpio.
Please wait...

[2009-12-07 05:47] ==> Building image "default"
[2009-12-07 05:47] ==> Running command: /sbin/mkinitcpio -k 2.6.32-ARCH -c
/etc/mkinitcpio.conf -g /boot/kernel26.img

[2009-12-07 05:47] :: Begin build
[2009-12-07 05:47] :: Parsing hook [base]
[2009-12-07 05:47] :: Parsing hook [udev]
[2009-12-07 05:47] :: Parsing hook [autodetect]
[2009-12-07 05:47] :: Parsing hook [sata]
[2009-12-07 05:48] :: Parsing hook [filesystems]
[2009-12-07 05:48] :: Generating module dependencies
[2009-12-07 05:48] :: Generating image '/boot/kernel26.img'...SUCCESS
[2009-12-07 05:48] ==> SUCCESS
[2009-12-07 05:48] ==> Building image "fallback"
[2009-12-07 05:48] ==> Running command: /sbin/mkinitcpio -k 2.6.32-ARCH -c
/etc/mkinitcpio.conf -g /boot/kernel26-fallback.img -S autodetect

[2009-12-07 05:48] :: Begin build
[2009-12-07 05:48] :: Parsing hook [base]
[2009-12-07 05:48] :: Parsing hook [udev]
[2009-12-07 05:48] :: Parsing hook [sata]
[2009-12-07 05:48] :: Parsing hook [filesystems]
[2009-12-07 05:48] :: Generating module dependencies
[2009-12-07 05:48] :: Generating image
'/boot/kernel26-fallback.img'...SUCCESS

[2009-12-07 05:48] ==> SUCCESS
[2009-12-07 05:48] upgraded kernel26 (2.6.31.6-1 -> 2.6.32-1)
[2009-12-07 05:48] upgraded kexec-tools (2.0.0-1 -> 2.0.1-1)
[2009-12-07 05:48] upgraded lib32-fontconfig (2.6.0-2 -> 2.8.0-1)
[2009-12-07 05:48] upgraded libcddb (1.3.2-1 -> 1.3.2-1.1)
[2009-12-07 05:48] upgraded libv4l (0.6.3-1 -> 0.6.3-2)
[2009-12-07 05:48] upgraded miro (2.5.3-1 -> 2.5.3-2)
[2009-12-07 05:48] upgraded mpd (0.15.5-2 -> 0.15.6-1)
[2009-12-07 05:48] if you are running kms in early mode please rebuild
your initrd
[2009-12-07 05:48] In order to use the new nouveau module, exit Xserver
and unload it manually.
[2009-12-07 05:48] upgraded nouveau-drm (0.0.15_20091120-1 ->
0.0.15_20091120-2)

nouveau upgrade failed
 

On Mon, Dec 7, 2009 at 6:33 AM, Andreas Radke <a.radke@arcor.de> wrote:
> Nouveau upgrade path was broken for me. It printed out to the screen
> something like "module 'nouveau' not found" while building the new initrd.
> It's not in the pacman.log.
>
> I'm using early kms mode. This probably happens because the new nouveau
> module is not yet present when the kernel is updated and new initrd is
> built.
>
> Maybe we should start to rebuild the initrd from nouveau post.update because
> we recommend early kms mode anyway whenever possible?
>

Why would you recommend such a thing ? I would rather disrecommend it
to avoid problems.

But it's true that the main problem when using initrd is forgetting to
rebuild it (as you experienced yourself), so having the package do
that automatically might help.. hmm..
What I don't like is forcing a rebuild in all cases, even when nouveau
is not even in the initrd. Is there a good way to detect that ?

nouveau upgrade failed
 

Andreas Radke schrieb:
Nouveau upgrade path was broken for me. It printed out to the screen
something like "module 'nouveau' not found" while building the new
initrd. It's not in the pacman.log.


I'm using early kms mode. This probably happens because the new nouveau
module is not yet present when the kernel is updated and new initrd is
built.


Maybe we should start to rebuild the initrd from nouveau post.update
because we recommend early kms mode anyway whenever possible?


After reboot kms wasn't enabled. I did pacman -S kernel26 again and this
time it picked up the module into the initrd.


That is to be expected, as nouveau depends on kernel26. I have asked Dan
a while ago if we can have "delayed post_install", such that certain
tasks can be queued for the end, after ALL packages have been upgraded.
No idea what he responded, but it is the only clean way to solve this.

nouveau upgrade failed
 

Am Montag 07 Dezember 2009 14:56:34 schrieb Thomas Bächler:
> That is to be expected, as nouveau depends on kernel26. I have asked Dan
> a while ago if we can have "delayed post_install", such that certain
> tasks can be queued for the end, after ALL packages have been upgraded.
> No idea what he responded, but it is the only clean way to solve this.

I think there were some discussion about hook scripts that pacman will execute
on certain events (e.g. to update desktop database, icon cache etc.). Running
mkinitcpio would be another use case.

--

Pierre Schmitz, https://users.archlinux.de/~pierre

nouveau upgrade failed
 

Pierre Schmitz wrote:

Am Montag 07 Dezember 2009 14:56:34 schrieb Thomas Bächler:
That is to be expected, as nouveau depends on kernel26. I have asked Dan
a while ago if we can have "delayed post_install", such that certain
tasks can be queued for the end, after ALL packages have been upgraded.
No idea what he responded, but it is the only clean way to solve this.


I think there were some discussion about hook scripts that pacman will execute
on certain events (e.g. to update desktop database, icon cache etc.). Running
mkinitcpio would be another use case.


I started writing about it here:
http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks
Still a long way off...