Created attachment 334486 [details] emerge --info
Created attachment 334488 [details] lspci lspci sees the NV43 [GeForce 6600 LE] (rev a2) in any case
What makes you believe it has anything to do with udev, or the udev's hwdb.bin? I can't find any indication of that based on current provided output.
Created attachment 334492 [details] dmesg nouveau does not load
Created attachment 334494 [details] dmesg nouveau loads ok (no /etc/udev/hwdb.bin)
(In reply to comment #3) > What makes you believe it has anything to do with udev, or the udev's > hwdb.bin? I can't find any indication of that based on current provided > output. The fact that it boots without /etc/udev/hwdb.bin with no problem and it is so easy reproducible with "udevadm hwdb --update". But what do you think where I sould look? By the way I found it because there are 3 Gentoo installations on the G5. (I use rsycn to keep them uptodate.) One of them had a very short hwdb.bin
(In reply to comment #6) > By the way I found it because there are 3 Gentoo installations on the G5. > (I use rsycn to keep them uptodate.) > One of them had a very short hwdb.bin And it's the box with unusual short hwdb.bin that fails to load the driver? Is /etc on it's own partition and/or does it have enough space to generate the .bin file? It's few megabytes.
Output of these? # emerge -pv hwids (is USE=udev enabled?) # emerge -pv sys-fs/udev (is USE=hwdb enabled?) # udevadm --update hwdb (try to use the --debug switch to get more information!) # ls -ld /etc/udev/hwdb.bin # ls -ld /etc/udev/hwdb.d/*
(In reply to comment #7) > (In reply to comment #6) > > By the way I found it because there are 3 Gentoo installations on the G5. > > (I use rsycn to keep them uptodate.) > > One of them had a very short hwdb.bin > > And it's the box with unusual short hwdb.bin that fails to load the driver? > Is /etc on it's own partition and/or does it have enough space to generate > the .bin file? It's few megabytes. It is the the one with the long hwdb.bin that fails to load the driver. There should be enough space everywhere on all of the 3 installations. Only /tmp is seperate. "recovery" and "service" are the two extra installations: michael@electra /mnt/recovery/etc/udev $ df -h Filesystem Size Used Avail Use% Mounted on rootfs 197G 20G 168G 11% / /dev/root 197G 20G 168G 11% / devtmpfs 2,0G 0 2,0G 0% /dev tmpfs 2,0G 348K 2,0G 1% /run shm 2,0G 0 2,0G 0% /dev/shm /dev/sdb5 2,0G 68M 1,9G 4% /tmp /dev/sdb6 197G 19G 168G 11% /mnt/recovery /dev/sdb7 50G 19G 28G 41% /mnt/service michael@electra /mnt/recovery/etc/udev $ ll total 16K -r--r--r-- 1 root root 105 Dec 19 13:55 hwdb.bin drwxr-xr-x 2 root root 4,0K Dec 19 13:55 hwdb.d drwxr-xr-x 2 root root 4,0K Dec 19 13:55 rules.d -rw-r--r-- 1 root root 44 Dec 19 13:55 udev.conf
(In reply to comment #8) > Output of these? > > # emerge -pv hwids (is USE=udev enabled?) > # emerge -pv sys-fs/udev (is USE=hwdb enabled?) > # udevadm --update hwdb (try to use the --debug switch to get more > information!) > # ls -ld /etc/udev/hwdb.bin > # ls -ld /etc/udev/hwdb.d/* electra ~ # emerge -pv hwids These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-apps/hwids-20130102 USE="udev" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB --------------------------------------------------------------------- electra ~ # emerge -pv sys-fs/udev These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-fs/udev-196-r1 USE="acl gudev hwdb keymap kmod openrc -doc -introspection (-selinux) -static-libs" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB --------------------------------------------------------------------- electra ~ # udevadm --debug hwdb --update calling: hwdb reading file '/usr/lib/udev/hwdb.d/20-OUI.hwdb' reading file '/usr/lib/udev/hwdb.d/20-acpi-vendor.hwdb' reading file '/usr/lib/udev/hwdb.d/20-bluetooth-vendor-product.hwdb' reading file '/usr/lib/udev/hwdb.d/20-pci-classes.hwdb' reading file '/usr/lib/udev/hwdb.d/20-pci-vendor-product.hwdb' reading file '/usr/lib/udev/hwdb.d/20-usb-classes.hwdb' reading file '/usr/lib/udev/hwdb.d/20-usb-vendor-product.hwdb' === trie in-memory === nodes: 3255800 bytes ( 81395) children arrays: 1302304 bytes ( 81394) values arrays: 983392 bytes ( 61462) strings: 1228629 bytes strings incoming: 3035331 bytes ( 193202) strings dedup'ed: 1860541 bytes ( 139364) === trie on-disk === size: 5467885 bytes header: 80 bytes nodes: 1953480 bytes ( 81395) child pointers: 1302304 bytes ( 81394) value pointers: 983392 bytes ( 61462) string store: 1228629 bytes strings start: 4239256 ------------------------------------------------------------------------- electra ~ # ls -ld /etc/udev/hwdb.bin -r--r--r-- 1 root root 5467885 Jan 7 11:21 /etc/udev/hwdb.bin ----------------------------------------------------------------------- electra ~ # ls -ld /etc/udev/hwdb.d/* ls: cannot access /etc/udev/hwdb.d/*: No such file or directory --------------------------------------------------------------------- The last one is just an empty directory, same as on my ~amd installation.
I upgraded to /sys-fs/udev-197-r1 (and re-emerged all packages which had rules in /usr/lib/udev) The problem seems to be gone: Now I've got a 5,3M large /etc/udev/hwdb.bin Thanks!
(In reply to comment #11) > The problem seems to be gone: Just for clarity: The nouveau-driver loads now also with the newly generated large 5,3M /etc/udev/hwdb.bin
