Doesn't the nvidia driver sort this out for you? It blacklists nouveau by means of /etc/modprobe.d/blacklist-nouveau.conf, which should get added into the initramfs. Blacklisting it will have the same effect as removing it entirely. If it hasn't 'stuck' then you can boot up, run "dracut -f", and reboot.

The alternative would be to add the right parameter to the kernel boot line. I think you just append "rdblacklist=nouveau". On an installed system, this goes in the kernel line in /boot/grub/grub.conf, but I don't know if that's quite how things work on a live USB. You might need to find the relevant file in the USB stick boot config.

(Also bear in mind that when you upgrade to Fedora 16 you'll be on grub2 rather than grub. I haven't done this yet with my live USB stick so I don't know how that affects things.)

James

On Fri, 2011-10-28 at 10:10 +0100, Tim Coote wrote:
Hi James
Thanks for the help on this. I've now managed to confirm that the overlay is persistent (I was using an invalid test).

My next immediate challenge is to remove the nouveau driver from initramfs. I can pull it out if I boot into runlevel 3 (as it used to be called) and then rmmod, but it would be better not to have it at all. Any pointers on how to get rid of it?

Tim
On 26 Oct 2011, at 10:03, Tim Coote wrote:

> Hi James
> All of the changes that I'm making are in the running environment. By hand - once the system's up and running, I dig around to work out what needs to change, then change it. Some of these changes I'd like to migrate into the kickstart/livesys, but I've got to work out what they are first. A good example would be that I need different graphics drivers, but I don't know the parameters a priori.
> 
> Tim
> On 26 Oct 2011, at 08:40, James Heather wrote:
> 
>> Hi Tim,
>> 
>> How are you making these changes? Are you doing so in the kickstart, in a %post section? If so, that probably won't work, because your code might get run before the code that sets the default firewall rules.
>> 
>> If you want such changes to be made via your kickstart file, you need to add the commands to the end of /etc/rc.d/init.d/livesys, so that they'll be run on first boot. See fedora-live-base.ks for details on how to go about it. (In fact, fedora-live-base.ks sets up the livesys file, and then fedira-live-desktop.ks has an example of how to add extra commands afterwards by means of 'cat >> /etc/rc.d.init.d/livesys << EOF'.)
>> 
>> James
>> 
>> On Tue, 2011-10-25 at 18:34 +0100, Tim Coote wrote:
>>> Thanks, James. That's what I was hoping. Further and better particulars will have to wait until I get back to the computer, I'm afraid.
>>> 
>>> Anything in particular?  
>>> 
>>> So far, I was I just enabling sshd (chkconfig --levels 345 sshd on), turning off the firewall (chkconfig --levels 345 iptables off)  and then "shutdown -r now".
>>> Upon reboot, no sshd. Now I know what to expect, I can dig around more specifically.
>>> 
>>> Tim
>>> On 25 Oct 2011, at 10:52, James Heather wrote:
>>> 
>>>> You've understood correctly. Changes anywhere that's under / should persist, except for temp-style directories: /tmp, /var/tmp, /var/cache/yum.
>>>> 
>>>> Something else must be going wrong. I think we'll need more details to work out what.
>>>> 
>>>> James
>>>> 
>>>> On Tue, 2011-10-25 at 10:50 +0100, Tim Coote wrote:
>>>>> Hullo
>>>>> I'm trying to use livecd to test fedora upgrades non-destructively. To make this work, I really need to be able to use the persistent overlay to fix drivers. I'm using the standard command: 
>>>>> 
>>>>> livecd-iso-to-disk --overlay-size-mb 2047 /path/to/live.iso /dev/sdb1
>>>>> 
>>>>> However, this is not working as I'd expect. If I boot from the resulting usb drive and change the configuration (eg to enable sshd), then the changes are lost on reboot.
>>>>> 
>>>>> Have I misunderstood how persistent overlays are supposed to work - I'd interpreted the documentation to mean that the overlay can persist changes from /, as well as just providing a persistent overlay to /home?
>>>>> 
>>>>> tia
>>>>> 
>>>>> Tim
>>>>> --
>>>>> livecd mailing list
>>>>> 
>>>>> 
>>> livecd@lists.fedoraproject.org
>>> 
>>>>> 
>>> https://admin.fedoraproject.org/mailman/listinfo/livecd
>>> 
>>>> 
>>>> --
>>>> livecd mailing list
>>>> 
>>> livecd@lists.fedoraproject.org
>>> 
>>>> 
>>> https://admin.fedoraproject.org/mailman/listinfo/livecd
>>> 
>>> 
>>> 
>>> --
>>> livecd mailing list
>>> 
>>> livecd@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/livecd
>> 
>> --
>> livecd mailing list
>> livecd@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/livecd
> 
> --
> livecd mailing list
> livecd@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/livecd

--
livecd mailing list
livecd@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/livecd