1:39 p.m.
Thx for the suggestion, this message has been forwared on the "RPM
Fusion developers discussion list" for public audience.
Please answear there instead.(once subscribed).
Few answears:
- setsebool will not be needed anymore (exept for the nvidia-smi
binary on x86 which is only used for tesla hardware).
- Creating a separate initramfs is probably the way to go. But I
wonder if that could be implemented as a dracut plugin instead, and
then generalised to others alternate proprietary drivers.
- There is improvements needed for a new packaging scheme that will
split installation and usage for proprietary driver. (it doesn't mean
the driver is installed that the driver is meant to be used).
2009/11/28 Walter Francis <wally(a)theblackmoor.net>:
Bleh, just discovered that redhat-lsb is not installed in all paths,
so
probably better to use /etc/rpm/macros.dist to get the release number...
Sorry for the spam, just didn't want to leave you with something that would be
broken on Live installs.
BTW, someone mentioned that the sebool stuff is probably better done outside
of a postinstall script, but I'm no spec writer so I leave that up to you.
;-) Just suggestions here on what would be very nice to have done, how it's
actually done is better decided by you. :) Unless I find any other glaring
mistakes I'll stop spamming you, hope I haven't been a bother.
#!/bin/sh
if getsebool allow_execstack | grep -q off; then
setsebool -P allow_execstack on
fi
# create new initrd/initramfs if necessary
if lsmod | grep -q nouveau; then
release=$(awk '/^%fedora/{print$2}' /etc/rpm/macros.dist)
if [ $release -gt 11 ]; then
# use new-kernel-pkg to create the initramfs and create a new
boot entry (see below)
/sbin/new-kernel-pkg --mkinitrd --dracut
--initrdfile=/boot/initramfs-`uname -r`-nvidia.img
--banner="Fedora NVidia" --make-default --install `uname -r`
fi
if [ $release -lt 12 ]; then
# non-dracut, use initrd filename, no --dracut
/sbin/new-kernel-pkg --mkinitrd
--initrdfile=/boot/initrd-`uname -r`-nvidia.img
--banner="Fedora NVidia" --make-default --install `uname -r`
fi
fi
--
Walter Francis
khayts.us
theblackmoor.net
unlimitedphoto.com
2:33 p.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
On Sunday 29 November 2009, Nicolas Chauvet wrote:
Thx for the suggestion, this message has been forwared on the
"RPM
Fusion developers discussion list" for public audience.
Please answear there instead.(once subscribed).
Few answears:
- setsebool will not be needed anymore (exept for the nvidia-smi
binary on x86 which is only used for tesla hardware).
- Creating a separate initramfs is probably the way to go. But I
wonder if that could be implemented as a dracut plugin instead, and
then generalised to others alternate proprietary drivers.
- There is improvements needed for a new packaging scheme that will
split installation and usage for proprietary driver. (it doesn't mean
the driver is installed that the driver is meant to be used).
2009/11/28 Walter Francis <wally(a)theblackmoor.net>:
> Bleh, just discovered that redhat-lsb is not installed in all paths, so
> probably better to use /etc/rpm/macros.dist to get the release number...
> Sorry for the spam, just didn't want to leave you with something that
> would be broken on Live installs.
>
> BTW, someone mentioned that the sebool stuff is probably better done
> outside of a postinstall script, but I'm no spec writer so I leave that
> up to you. ;-) Just suggestions here on what would be very nice to have
> done, how it's actually done is better decided by you. :) Unless I find
> any other glaring mistakes I'll stop spamming you, hope I haven't been a
> bother.
>
> #!/bin/sh
>
> if getsebool allow_execstack | grep -q off; then
> setsebool -P allow_execstack on
> fi
>
> # create new initrd/initramfs if necessary
> if lsmod | grep -q nouveau; then
> release=$(awk '/^%fedora/{print$2}' /etc/rpm/macros.dist)
> if [ $release -gt 11 ]; then
> # use new-kernel-pkg to create the initramfs and create a
> new boot entry (see below)
> /sbin/new-kernel-pkg --mkinitrd --dracut
> --initrdfile=/boot/initramfs-`uname -r`-nvidia.img
> --banner="Fedora NVidia" --make-default --install `uname -r`
> fi
> if [ $release -lt 12 ]; then
> # non-dracut, use initrd filename, no --dracut
> /sbin/new-kernel-pkg --mkinitrd
> --initrdfile=/boot/initrd-`uname -r`-nvidia.img
> --banner="Fedora NVidia" --make-default --install `uname -r`
> fi
> fi
>
> --
> Walter Francis
>
> khayts.us
> theblackmoor.net
> unlimitedphoto.com
Isn't adding rdblacklist=nouveau to grub.conf less intrusive?
9:52 p.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
2009/11/29 Neal Becker <ndbecker2(a)gmail.com>:
On Sunday 29 November 2009, Nicolas Chauvet wrote:
> Thx for the suggestion, this message has been forwared on the "RPM
> Fusion developers discussion list" for public audience.
> Please answear there instead.(once subscribed).
>
> Few answears:
> - setsebool will not be needed anymore (exept for the nvidia-smi
> binary on x86 which is only used for tesla hardware).
> - Creating a separate initramfs is probably the way to go. But I
> wonder if that could be implemented as a dracut plugin instead, and
> then generalised to others alternate proprietary drivers.
> - There is improvements needed for a new packaging scheme that will
> split installation and usage for proprietary driver. (it doesn't mean
> the driver is installed that the driver is meant to be used).
>
> 2009/11/28 Walter Francis <wally(a)theblackmoor.net>:
> > Bleh, just discovered that redhat-lsb is not installed in all paths, so
> > probably better to use /etc/rpm/macros.dist to get the release number...
> > Sorry for the spam, just didn't want to leave you with something that
> > would be broken on Live installs.
> >
> > BTW, someone mentioned that the sebool stuff is probably better done
> > outside of a postinstall script, but I'm no spec writer so I leave that
> > up to you. ;-) Just suggestions here on what would be very nice to have
> > done, how it's actually done is better decided by you. :) Unless I find
> > any other glaring mistakes I'll stop spamming you, hope I haven't been
a
> > bother.
> >
> > #!/bin/sh
> >
> > if getsebool allow_execstack | grep -q off; then
> > setsebool -P allow_execstack on
> > fi
> >
> > # create new initrd/initramfs if necessary
> > if lsmod | grep -q nouveau; then
> > release=$(awk '/^%fedora/{print$2}' /etc/rpm/macros.dist)
> > if [ $release -gt 11 ]; then
> > # use new-kernel-pkg to create the initramfs and create a
> > new boot entry (see below)
> > /sbin/new-kernel-pkg --mkinitrd --dracut
> > --initrdfile=/boot/initramfs-`uname -r`-nvidia.img
> > --banner="Fedora NVidia" --make-default --install `uname -r`
> > fi
> > if [ $release -lt 12 ]; then
> > # non-dracut, use initrd filename, no --dracut
> > /sbin/new-kernel-pkg --mkinitrd
> > --initrdfile=/boot/initrd-`uname -r`-nvidia.img
> > --banner="Fedora NVidia" --make-default --install `uname -r`
> > fi
> > fi
> >
> > --
> > Walter Francis
> >
> > khayts.us
> > theblackmoor.net
> > unlimitedphoto.com
>
Isn't adding rdblacklist=nouveau to grub.conf less intrusive?
not, the nouveau
kms remains loaded and leave things in the unsafe random side.
That might work for your hardware/usage , it will not work for others...
So that's even do not worth to be documented.
Nicolas (kwizart)
6:35 p.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
2009/11/29 Neal Becker <ndbecker2(a)gmail.com>:
> On Sunday 29 November 2009, Nicolas Chauvet wrote:
>> Thx for the suggestion, this message has been forwared on the "RPM
>> Fusion developers discussion list" for public audience.
>> Please answear there instead.(once subscribed).
>>
>> Few answears:
>> - setsebool will not be needed anymore (exept for the nvidia-smi
>> binary on x86 which is only used for tesla hardware).
>> - Creating a separate initramfs is probably the way to go. But I
>> wonder if that could be implemented as a dracut plugin instead, and
>> then generalised to others alternate proprietary drivers.
>> - There is improvements needed for a new packaging scheme that will
>> split installation and usage for proprietary driver. (it doesn't mean
>> the driver is installed that the driver is meant to be used).
>>
>> 2009/11/28 Walter Francis <wally(a)theblackmoor.net>:
>> > Bleh, just discovered that redhat-lsb is not installed in all paths, so
>> > probably better to use /etc/rpm/macros.dist to get the release number...
>> > Sorry for the spam, just didn't want to leave you with something that
>> > would be broken on Live installs.
>> >
>> > BTW, someone mentioned that the sebool stuff is probably better done
>> > outside of a postinstall script, but I'm no spec writer so I leave that
>> > up to you. ;-) Just suggestions here on what would be very nice to have
>> > done, how it's actually done is better decided by you. :) Unless I
find
>> > any other glaring mistakes I'll stop spamming you, hope I haven't
been a
>> > bother.
>> >
>> > #!/bin/sh
>> >
>> > if getsebool allow_execstack | grep -q off; then
>> > setsebool -P allow_execstack on
>> > fi
>> >
>> > # create new initrd/initramfs if necessary
>> > if lsmod | grep -q nouveau; then
>> > release=$(awk '/^%fedora/{print$2}' /etc/rpm/macros.dist)
>> > if [ $release -gt 11 ]; then
>> > # use new-kernel-pkg to create the initramfs and create a
>> > new boot entry (see below)
>> > /sbin/new-kernel-pkg --mkinitrd --dracut
>> > --initrdfile=/boot/initramfs-`uname -r`-nvidia.img
>> > --banner="Fedora NVidia" --make-default --install `uname -r`
>> > fi
>> > if [ $release -lt 12 ]; then
>> > # non-dracut, use initrd filename, no --dracut
>> > /sbin/new-kernel-pkg --mkinitrd
>> > --initrdfile=/boot/initrd-`uname -r`-nvidia.img
>> > --banner="Fedora NVidia" --make-default --install `uname -r`
>> > fi
>> > fi
>> >
>> > --
>> > Walter Francis
>> >
>> > khayts.us
>> > theblackmoor.net
>> > unlimitedphoto.com
>>
>
> Isn't adding rdblacklist=nouveau to grub.conf less intrusive?
not, the nouveau kms remains loaded and leave things in the unsafe random
side.
That might work for your hardware/usage , it will not work for others...
So that's even do not worth to be documented.
Nicolas (kwizart)
BTW all, my original email to Kwizart was just basically a suggestion on how
it would be nice to simplify things, with an example of "a way". It wasn't
to
suggest "the way" to do it. Sounds like you guys have thought it out better
than I have, in terms of a separate selinux package to handle the nvidia kmod
specific rules, etc. Just look forward to our end users being able to
hopefully just do two steps: 1) install rpmfusion, 2) yum install
[a]kmod-nvidia[-PAE].
--
Walter Francis
khayts.us
theblackmoor.net
unlimitedphoto.com
8:02 p.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
On Sun, 2009-11-29 at 22:52 +0100, Nicolas Chauvet wrote:
> Isn't adding rdblacklist=nouveau to grub.conf less
intrusive?
not, the nouveau kms remains loaded and leave things in the unsafe random side.
That might work for your hardware/usage , it will not work for others...
So that's even do not worth to be documented.
Are you sure? The combination of rdblacklist kernel parameter and
blacklist directive in /etc/modprobe.d should prevent the module being
loaded at all even if it's present in the initramfs. Have you tried
rdblacklist? It's a dracut parameter which should prevent the module
specified from being loaded from the initramfs.
BTW, I believe the canonical way to derive the current release version
is to parse /etc/redhat-release , which is part of the fedora-release
package.
--
adamw
8:52 p.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
2009/12/2 Adam Williamson <adamwill(a)shaw.ca>:
On Sun, 2009-11-29 at 22:52 +0100, Nicolas Chauvet wrote:
> > Isn't adding rdblacklist=nouveau to grub.conf less intrusive?
> not, the nouveau kms remains loaded and leave things in the unsafe random side.
> That might work for your hardware/usage , it will not work for others...
> So that's even do not worth to be documented.
Are you sure? The combination of rdblacklist kernel parameter and
blacklist directive in /etc/modprobe.d should prevent the module being
loaded at all even if it's present in the initramfs. Have you tried
rdblacklist? It's a dracut parameter which should prevent the module
specified from being loaded from the initramfs.
I'm not sure at all, nor have
done tests. But I think I saw that
nouveau still remain loaded. if other options are used on the grub
line.
Having the nouveau.ko still present in the initramfs leave things in
the unsafe side for those who only want to use nvidia. But on the
other hand, if only rdblacklist=nouveau,radeon is needed to prevent
conflicts with closed source drivers and to avoid to rebuild the
initramfs, that will help.
Then using /etc/modprobe.d/ for blacklist or not can be deceided if
users want to keep the capability to switch between FOSS or closed
drivers. (so KMS drivers could be enabled by a grub, entry duplicated
for each given kernel).
BTW, I believe the canonical way to derive the current release
version
is to parse /etc/redhat-release , which is part of the fedora-release
package.
Using /etc/system-release would be even better. But in this case, I
guess it will be easier to pick dracut style if the dracut binary is
available on the system.
12:07 a.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
On Wednesday 02 December 2009, Nicolas Chauvet wrote:
2009/12/2 Adam Williamson <adamwill(a)shaw.ca>:
> On Sun, 2009-11-29 at 22:52 +0100, Nicolas Chauvet wrote:
>> > Isn't adding rdblacklist=nouveau to grub.conf less intrusive?
>>
>> not, the nouveau kms remains loaded and leave things in the unsafe
>> random side. That might work for your hardware/usage , it will not work
>> for others... So that's even do not worth to be documented.
>
> Are you sure? The combination of rdblacklist kernel parameter and
> blacklist directive in /etc/modprobe.d should prevent the module being
> loaded at all even if it's present in the initramfs. Have you tried
> rdblacklist? It's a dracut parameter which should prevent the module
> specified from being loaded from the initramfs.
I'm not sure at all, nor have done tests. But I think I saw that
nouveau still remain loaded. if other options are used on the grub
line.
Having the nouveau.ko still present in the initramfs leave things in
the unsafe side for those who only want to use nvidia. But on the
other hand, if only rdblacklist=nouveau,radeon is needed to prevent
conflicts with closed source drivers and to avoid to rebuild the
initramfs, that will help.
Then using /etc/modprobe.d/ for blacklist or not can be deceided if
users want to keep the capability to switch between FOSS or closed
drivers. (so KMS drivers could be enabled by a grub, entry duplicated
for each given kernel).
I can confirm that nouveau is not loaded using rdblacklist.
8:46 a.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
2009/12/3 Neal Becker <ndbecker2(a)gmail.com>:
On Wednesday 02 December 2009, Nicolas Chauvet wrote:
> 2009/12/2 Adam Williamson <adamwill(a)shaw.ca>:
> > On Sun, 2009-11-29 at 22:52 +0100, Nicolas Chauvet wrote:
> >> > Isn't adding rdblacklist=nouveau to grub.conf less intrusive?
> >>
> >> not, the nouveau kms remains loaded and leave things in the unsafe
> >> random side. That might work for your hardware/usage , it will not work
> >> for others... So that's even do not worth to be documented.
> >
> > Are you sure? The combination of rdblacklist kernel parameter and
> > blacklist directive in /etc/modprobe.d should prevent the module being
> > loaded at all even if it's present in the initramfs. Have you tried
> > rdblacklist? It's a dracut parameter which should prevent the module
> > specified from being loaded from the initramfs.
>
> I'm not sure at all, nor have done tests. But I think I saw that
> nouveau still remain loaded. if other options are used on the grub
> line.
> Having the nouveau.ko still present in the initramfs leave things in
> the unsafe side for those who only want to use nvidia. But on the
> other hand, if only rdblacklist=nouveau,radeon is needed to prevent
> conflicts with closed source drivers and to avoid to rebuild the
> initramfs, that will help.
>
> Then using /etc/modprobe.d/ for blacklist or not can be deceided if
> users want to keep the capability to switch between FOSS or closed
> drivers. (so KMS drivers could be enabled by a grub, entry duplicated
> for each given kernel).
>
I can confirm that nouveau is not loaded using rdblacklist.
But which hardware are you using ? was initramfs recreated already as
the /etc/modprobe.d/blacklist-nouveau.conf is present in the drivers
or do you have deleted it ?
Nicolas (kwizart)
12:32 p.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
On Thursday 03 December 2009, Nicolas Chauvet wrote:
2009/12/3 Neal Becker <ndbecker2(a)gmail.com>:
> On Wednesday 02 December 2009, Nicolas Chauvet wrote:
>> 2009/12/2 Adam Williamson <adamwill(a)shaw.ca>:
>> > On Sun, 2009-11-29 at 22:52 +0100, Nicolas Chauvet wrote:
>> >> > Isn't adding rdblacklist=nouveau to grub.conf less intrusive?
>> >>
>> >> not, the nouveau kms remains loaded and leave things in the unsafe
>> >> random side. That might work for your hardware/usage , it will not
>> >> work for others... So that's even do not worth to be documented.
>> >
>> > Are you sure? The combination of rdblacklist kernel parameter and
>> > blacklist directive in /etc/modprobe.d should prevent the module being
>> > loaded at all even if it's present in the initramfs. Have you tried
>> > rdblacklist? It's a dracut parameter which should prevent the module
>> > specified from being loaded from the initramfs.
>>
>> I'm not sure at all, nor have done tests. But I think I saw that
>> nouveau still remain loaded. if other options are used on the grub
>> line.
>> Having the nouveau.ko still present in the initramfs leave things in
>> the unsafe side for those who only want to use nvidia. But on the
>> other hand, if only rdblacklist=nouveau,radeon is needed to prevent
>> conflicts with closed source drivers and to avoid to rebuild the
>> initramfs, that will help.
>>
>> Then using /etc/modprobe.d/ for blacklist or not can be deceided if
>> users want to keep the capability to switch between FOSS or closed
>> drivers. (so KMS drivers could be enabled by a grub, entry duplicated
>> for each given kernel).
>
> I can confirm that nouveau is not loaded using rdblacklist.
But which hardware are you using ?
How would that make any difference?
FYI, nVidia Corporation GeForce 8600M GS (rev a1)
was initramfs recreated already as
the /etc/modprobe.d/blacklist-nouveau.conf is present in the drivers
or do you have deleted it ?
I did not recreate initramfs, but I have updated kernels since initial install
(which will recreate initramfs). All I did is:
1. Install nvidia from rpmfusion, which adds /etc/modprobe.d/blacklist-
nouveau.conf
2. Add rdblacklist=nouveau to grub.conf
To be sure, this procedure could be retested on a new install, since I can't
prove that it isn't the initramfs caused by a kernel update that makes it work
here.
4:31 p.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
On Thu, 2009-12-03 at 07:32 -0500, Neal Becker wrote:
To be sure, this procedure could be retested on a new install, since
I can't
prove that it isn't the initramfs caused by a kernel update that makes it work
here.
It's not too hard to check:
[root@adam shapefile]# lsinitrd /boot/initramfs-2.6.31.6-145.fc12.x86_64.img | grep
nouveau
drwxr-xr-x 2 root root 0 Nov 26 09:44
lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau
-rwxr--r-- 1 root root 714040 Nov 26 09:44
lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau/nouveau.ko
lrwxrwxrwx 1 root root 34 Nov 26 09:44 usr/lib64/libdrm_nouveau.so.1 ->
/usr/lib64/libdrm_nouveau.so.1.0.0
-rwxr-xr-x 1 root root 20256 Nov 19 16:45 usr/lib64/libdrm_nouveau.so.1.0.0
init
i.e., use lsinitrd to see if your initramfs actually has a nouveau
module in it. also, boot without the rdblacklist parameter and see if
nouveau gets loaded.
--
adamw
7:38 p.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
On Thursday 03 December 2009, Adam Williamson wrote:
On Thu, 2009-12-03 at 07:32 -0500, Neal Becker wrote:
> To be sure, this procedure could be retested on a new install, since I
> can't prove that it isn't the initramfs caused by a kernel update that
> makes it work here.
It's not too hard to check:
[root@adam shapefile]# lsinitrd
/boot/initramfs-2.6.31.6-145.fc12.x86_64.img | grep nouveau drwxr-xr-x
2 root root 0 Nov 26 09:44
lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau
-rwxr--r-- 1 root root 714040 Nov 26 09:44
lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau/nouvea
u.ko lrwxrwxrwx 1 root root 34 Nov 26 09:44
usr/lib64/libdrm_nouveau.so.1 -> /usr/lib64/libdrm_nouveau.so.1.0.0
-rwxr-xr-x 1 root root 20256 Nov 19 16:45
usr/lib64/libdrm_nouveau.so.1.0.0 init
i.e., use lsinitrd to see if your initramfs actually has a nouveau
module in it. also, boot without the rdblacklist parameter and see if
nouveau gets loaded.
[nbecker@nbecker1 jupiter]$ lsinitrd /boot/initramfs-2.6.31.6-145.fc12.x86_64.img | grep
nouveau
-rw-r--r-- 1 root root 185 Nov 3 17:13
etc/modprobe.d/blacklist-nouveau.conf
-rwxr-xr-x 1 root root 20256 Nov 4 22:14 usr/lib64/libdrm_nouveau.so.1.0.0
lrwxrwxrwx 1 root root 34 Dec 1 14:16 usr/lib64/libdrm_nouveau.so.1 ->
/usr/lib64/libdrm_nouveau.so.1.0.0
drwxr-xr-x 2 root root 0 Dec 1 14:16
lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau
-rwxr--r-- 1 root root 714040 Dec 1 14:16
lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau/nouveau.ko
init
[nbecker@nbecker1 jupiter]$ uname -r
2.6.31.6-145.fc12.x86_64
So, it seems my current working initramfs DOES have nouveau. However, having
the module present is not the same as having it loaded. Doesn't kernel update
rebuild initramfs? I see the data/time of /boot/initramfs is the same as the update
of grub.conf.
7:41 p.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
On Thursday 03 December 2009, Adam Williamson wrote:
On Thu, 2009-12-03 at 07:32 -0500, Neal Becker wrote:
> To be sure, this procedure could be retested on a new install, since I
> can't prove that it isn't the initramfs caused by a kernel update that
> makes it work here.
It's not too hard to check:
[root@adam shapefile]# lsinitrd
/boot/initramfs-2.6.31.6-145.fc12.x86_64.img | grep nouveau drwxr-xr-x
2 root root 0 Nov 26 09:44
lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau
-rwxr--r-- 1 root root 714040 Nov 26 09:44
lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau/nouvea
u.ko lrwxrwxrwx 1 root root 34 Nov 26 09:44
usr/lib64/libdrm_nouveau.so.1 -> /usr/lib64/libdrm_nouveau.so.1.0.0
-rwxr-xr-x 1 root root 20256 Nov 19 16:45
usr/lib64/libdrm_nouveau.so.1.0.0 init
i.e., use lsinitrd to see if your initramfs actually has a nouveau
module in it. also, boot without the rdblacklist parameter and see if
nouveau gets loaded.
[nbecker@nbecker1 jupiter]$ lsinitrd
/boot/initramfs-2.6.31.6-145.fc12.x86_64.img | grep nouveau
-rw-r--r-- 1 root root 185 Nov 3 17:13
etc/modprobe.d/blacklist-nouveau.conf
-rwxr-xr-x 1 root root 20256 Nov 4 22:14
usr/lib64/libdrm_nouveau.so.1.0.0
lrwxrwxrwx 1 root root 34 Dec 1 14:16
usr/lib64/libdrm_nouveau.so.1 -> /usr/lib64/libdrm_nouveau.so.1.0.0
drwxr-xr-x 2 root root 0 Dec 1 14:16
lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau
-rwxr--r-- 1 root root 714040 Dec 1 14:16
lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau/nouveau.ko
init
[nbecker@nbecker1 jupiter]$ uname -r
2.6.31.6-145.fc12.x86_64
So, it seems my current working initramfs DOES have nouveau. However, having
the module present is not the same as having it loaded. Doesn't kernel update
rebuild initramfs? I see the data/time of /boot/initramfs is the same as the
update
of grub.conf.
11:09 p.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
2009/12/3 Neal Becker <ndbecker2(a)gmail.com>:
On Thursday 03 December 2009, Adam Williamson wrote:
> On Thu, 2009-12-03 at 07:32 -0500, Neal Becker wrote:
> > To be sure, this procedure could be retested on a new install, since I
> > can't prove that it isn't the initramfs caused by a kernel update that
> > makes it work here.
>
> It's not too hard to check:
>
> [root@adam shapefile]# lsinitrd
> /boot/initramfs-2.6.31.6-145.fc12.x86_64.img | grep nouveau drwxr-xr-x
> 2 root root 0 Nov 26 09:44
> lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau
> -rwxr--r-- 1 root root 714040 Nov 26 09:44
> lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau/nouvea
> u.ko lrwxrwxrwx 1 root root 34 Nov 26 09:44
> usr/lib64/libdrm_nouveau.so.1 -> /usr/lib64/libdrm_nouveau.so.1.0.0
> -rwxr-xr-x 1 root root 20256 Nov 19 16:45
> usr/lib64/libdrm_nouveau.so.1.0.0 init
>
> i.e., use lsinitrd to see if your initramfs actually has a nouveau
> module in it. also, boot without the rdblacklist parameter and see if
> nouveau gets loaded.
>
[nbecker@nbecker1 jupiter]$ lsinitrd
/boot/initramfs-2.6.31.6-145.fc12.x86_64.img | grep nouveau
-rw-r--r-- 1 root root 185 Nov 3 17:13
etc/modprobe.d/blacklist-nouveau.conf
-rwxr-xr-x 1 root root 20256 Nov 4 22:14
usr/lib64/libdrm_nouveau.so.1.0.0
lrwxrwxrwx 1 root root 34 Dec 1 14:16
usr/lib64/libdrm_nouveau.so.1 -> /usr/lib64/libdrm_nouveau.so.1.0.0
drwxr-xr-x 2 root root 0 Dec 1 14:16
lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau
-rwxr--r-- 1 root root 714040 Dec 1 14:16
lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau/nouveau.ko
init
[nbecker@nbecker1 jupiter]$ uname -r
2.6.31.6-145.fc12.x86_64
On usual initramfs generated after nvidia drivers got
installed:
$ lsinitrd /boot/initramfs-2.6.31.6-145.fc12.i686.img |grep blacklist
-rw-r--r-- 1 root root 845 Jul 26 13:04
etc/modprobe.d/blacklist.conf
-rw-r--r-- 1 root root 185 Nov 14 22:34
etc/modprobe.d/blacklist-nouveau.conf
$ lsinitrd /boot/initramfs-2.6.31.6-145.fc12.i686.img |grep nouveau
-rwxr-xr-x 1 root root 18828 Nov 5 04:14
usr/lib/libdrm_nouveau.so.1.0.0
lrwxrwxrwx 1 root root 32 Dec 3 20:37
usr/lib/libdrm_nouveau.so.1 -> /usr/lib/libdrm_nouveau.so.1.0.0
-rw-r--r-- 1 root root 185 Nov 14 22:34
etc/modprobe.d/blacklist-nouveau.conf
drwxr-xr-x 2 root root 0 Dec 3 20:38
lib/modules/2.6.31.6-145.fc12.i686/kernel/drivers/gpu/drm/nouveau
-rwxr--r-- 1 root root 573968 Dec 3 20:38
lib/modules/2.6.31.6-145.fc12.i686/kernel/drivers/gpu/drm/nouveau/nouveau.ko
init
So nouveau remains present in the initramfs despite been de-activated
automatically by the blacklist-nouveau.conf ?!
I expected nouveau not to be present in the initrd for the F-11 case
once blacklist-nouveau.conf is present.
Nicolas (kwizart)
12:24 a.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
On Thursday 03 December 2009, Nicolas Chauvet wrote:
2009/12/3 Neal Becker <ndbecker2(a)gmail.com>:
> On Thursday 03 December 2009, Adam Williamson wrote:
>> On Thu, 2009-12-03 at 07:32 -0500, Neal Becker wrote:
>> > To be sure, this procedure could be retested on a new install, since I
>> > can't prove that it isn't the initramfs caused by a kernel update
that
>> > makes it work here.
>>
>> It's not too hard to check:
>>
>> [root@adam shapefile]# lsinitrd
>> /boot/initramfs-2.6.31.6-145.fc12.x86_64.img | grep nouveau drwxr-xr-x
>> 2 root root 0 Nov 26 09:44
>> lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau
>> -rwxr--r-- 1 root root 714040 Nov 26 09:44
>> lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau/nou
>>vea u.ko lrwxrwxrwx 1 root root 34 Nov 26 09:44
>> usr/lib64/libdrm_nouveau.so.1 -> /usr/lib64/libdrm_nouveau.so.1.0.0
>> -rwxr-xr-x 1 root root 20256 Nov 19 16:45
>> usr/lib64/libdrm_nouveau.so.1.0.0 init
>>
>> i.e., use lsinitrd to see if your initramfs actually has a nouveau
>> module in it. also, boot without the rdblacklist parameter and see if
>> nouveau gets loaded.
>
> [nbecker@nbecker1 jupiter]$ lsinitrd
> /boot/initramfs-2.6.31.6-145.fc12.x86_64.img | grep nouveau
> -rw-r--r-- 1 root root 185 Nov 3 17:13
> etc/modprobe.d/blacklist-nouveau.conf
> -rwxr-xr-x 1 root root 20256 Nov 4 22:14
> usr/lib64/libdrm_nouveau.so.1.0.0
> lrwxrwxrwx 1 root root 34 Dec 1 14:16
> usr/lib64/libdrm_nouveau.so.1 -> /usr/lib64/libdrm_nouveau.so.1.0.0
> drwxr-xr-x 2 root root 0 Dec 1 14:16
> lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau
> -rwxr--r-- 1 root root 714040 Dec 1 14:16
> lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau/nouve
>au.ko init
>
> [nbecker@nbecker1 jupiter]$ uname -r
> 2.6.31.6-145.fc12.x86_64
On usual initramfs generated after nvidia drivers got installed:
$ lsinitrd /boot/initramfs-2.6.31.6-145.fc12.i686.img |grep blacklist
-rw-r--r-- 1 root root 845 Jul 26 13:04
etc/modprobe.d/blacklist.conf
-rw-r--r-- 1 root root 185 Nov 14 22:34
etc/modprobe.d/blacklist-nouveau.conf
$ lsinitrd /boot/initramfs-2.6.31.6-145.fc12.i686.img |grep nouveau
-rwxr-xr-x 1 root root 18828 Nov 5 04:14
usr/lib/libdrm_nouveau.so.1.0.0
lrwxrwxrwx 1 root root 32 Dec 3 20:37
usr/lib/libdrm_nouveau.so.1 -> /usr/lib/libdrm_nouveau.so.1.0.0
-rw-r--r-- 1 root root 185 Nov 14 22:34
etc/modprobe.d/blacklist-nouveau.conf
drwxr-xr-x 2 root root 0 Dec 3 20:38
lib/modules/2.6.31.6-145.fc12.i686/kernel/drivers/gpu/drm/nouveau
-rwxr--r-- 1 root root 573968 Dec 3 20:38
lib/modules/2.6.31.6-145.fc12.i686/kernel/drivers/gpu/drm/nouveau/nouveau.k
o init
So nouveau remains present in the initramfs despite been de-activated
automatically by the blacklist-nouveau.conf ?!
I expected nouveau not to be present in the initrd for the F-11 case
once blacklist-nouveau.conf is present.
Nicolas (kwizart)
Present in initramfs, but not loaded into kernel. So, I believe rdblacklist
works.
8:53 a.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
2009/12/4 Neal Becker <ndbecker2(a)gmail.com>:
On Thursday 03 December 2009, Nicolas Chauvet wrote:
> 2009/12/3 Neal Becker <ndbecker2(a)gmail.com>:
> > On Thursday 03 December 2009, Adam Williamson wrote:
> >> On Thu, 2009-12-03 at 07:32 -0500, Neal Becker wrote:
> >> > To be sure, this procedure could be retested on a new install, since I
> >> > can't prove that it isn't the initramfs caused by a kernel
update that
> >> > makes it work here.
> >>
> >> It's not too hard to check:
> >>
> >> [root@adam shapefile]# lsinitrd
> >> /boot/initramfs-2.6.31.6-145.fc12.x86_64.img | grep nouveau drwxr-xr-x
> >> 2 root root 0 Nov 26 09:44
> >> lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau
> >> -rwxr--r-- 1 root root 714040 Nov 26 09:44
> >> lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau/nou
> >>vea u.ko lrwxrwxrwx 1 root root 34 Nov 26 09:44
> >> usr/lib64/libdrm_nouveau.so.1 -> /usr/lib64/libdrm_nouveau.so.1.0.0
> >> -rwxr-xr-x 1 root root 20256 Nov 19 16:45
> >> usr/lib64/libdrm_nouveau.so.1.0.0 init
> >>
> >> i.e., use lsinitrd to see if your initramfs actually has a nouveau
> >> module in it. also, boot without the rdblacklist parameter and see if
> >> nouveau gets loaded.
> >
> > [nbecker@nbecker1 jupiter]$ lsinitrd
> > /boot/initramfs-2.6.31.6-145.fc12.x86_64.img | grep nouveau
> > -rw-r--r-- 1 root root 185 Nov 3 17:13
> > etc/modprobe.d/blacklist-nouveau.conf
> > -rwxr-xr-x 1 root root 20256 Nov 4 22:14
> > usr/lib64/libdrm_nouveau.so.1.0.0
> > lrwxrwxrwx 1 root root 34 Dec 1 14:16
> > usr/lib64/libdrm_nouveau.so.1 -> /usr/lib64/libdrm_nouveau.so.1.0.0
> > drwxr-xr-x 2 root root 0 Dec 1 14:16
> > lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau
> > -rwxr--r-- 1 root root 714040 Dec 1 14:16
> > lib/modules/2.6.31.6-145.fc12.x86_64/kernel/drivers/gpu/drm/nouveau/nouve
> >au.ko init
> >
> > [nbecker@nbecker1 jupiter]$ uname -r
> > 2.6.31.6-145.fc12.x86_64
>
> On usual initramfs generated after nvidia drivers got installed:
> $ lsinitrd /boot/initramfs-2.6.31.6-145.fc12.i686.img |grep blacklist
> -rw-r--r-- 1 root root 845 Jul 26 13:04
> etc/modprobe.d/blacklist.conf
> -rw-r--r-- 1 root root 185 Nov 14 22:34
> etc/modprobe.d/blacklist-nouveau.conf
> $ lsinitrd /boot/initramfs-2.6.31.6-145.fc12.i686.img |grep nouveau
> -rwxr-xr-x 1 root root 18828 Nov 5 04:14
> usr/lib/libdrm_nouveau.so.1.0.0
> lrwxrwxrwx 1 root root 32 Dec 3 20:37
> usr/lib/libdrm_nouveau.so.1 -> /usr/lib/libdrm_nouveau.so.1.0.0
> -rw-r--r-- 1 root root 185 Nov 14 22:34
> etc/modprobe.d/blacklist-nouveau.conf
> drwxr-xr-x 2 root root 0 Dec 3 20:38
> lib/modules/2.6.31.6-145.fc12.i686/kernel/drivers/gpu/drm/nouveau
> -rwxr--r-- 1 root root 573968 Dec 3 20:38
> lib/modules/2.6.31.6-145.fc12.i686/kernel/drivers/gpu/drm/nouveau/nouveau.k
> o init
> So nouveau remains present in the initramfs despite been de-activated
> automatically by the blacklist-nouveau.conf ?!
> I expected nouveau not to be present in the initrd for the F-11 case
> once blacklist-nouveau.conf is present.
>
> Nicolas (kwizart)
>
Present in initramfs, but not loaded into kernel. So, I believe rdblacklist
works.
Yep, it works, exept that i'm not using rdblacklist at all.
3:28 p.m.
New subject: Suggestion to simplify initial kmod-nvidia install (w/script correction)
On Fri, 04 Dec 2009 09:53:19 +0100, Nicolas Chauvet <kwizart(a)gmail.com>
wrote:
2009/12/4 Neal Becker <ndbecker2(a)gmail.com>:
> Present in initramfs, but not loaded into kernel. So, I believe
> rdblacklist
> works.
Yep, it works, exept that i'm not using rdblacklist at all.
We're obviously a bit confused here; I think we need to test all the
possibilities to see exactly what happens in each case. I can try and take
a look at this when I get back from FUDcon...
--
adamw
5467
days inactive
5473
days old
rpmfusion-developers@lists.rpmfusion.org
15 comments
4 participants
participants (4)
-
Adam Williamson -
Neal Becker -
Nicolas Chauvet -
Walter Francis