persistent overlay

[Tim Coote]

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

[James Heather]

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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/livecd

[Tim Coote]

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(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/livecd
>  
>  --
>  livecd mailing list
>  livecd(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/livecd

[James Heather]

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(a)lists.fedoraproject.org
>  >> https://admin.fedoraproject.org/mailman/listinfo/livecd
>  > 
>  > --
>  > livecd mailing list
>  > livecd(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/livecd
>  
>  
>  --
>  livecd mailing list
>  livecd(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/livecd

[Tim Coote]

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(a)lists.fedoraproject.org
> > 
> > >> 
> > https://admin.fedoraproject.org/mailman/listinfo/livecd
> > 
> > > 
> > > --
> > > livecd mailing list
> > > 
> > livecd(a)lists.fedoraproject.org
> > 
> > > 
> > https://admin.fedoraproject.org/mailman/listinfo/livecd
> > 
> > 
> > 
> > --
> > livecd mailing list
> > 
> > livecd(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/livecd
>  
>  --
>  livecd mailing list
>  livecd(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/livecd

[Tim Coote]

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(a)lists.fedoraproject.org
> >> 
> >>>> 
> >> https://admin.fedoraproject.org/mailman/listinfo/livecd
> >> 
> >>> 
> >>> --
> >>> livecd mailing list
> >>> 
> >> livecd(a)lists.fedoraproject.org
> >> 
> >>> 
> >> https://admin.fedoraproject.org/mailman/listinfo/livecd
> >> 
> >> 
> >> 
> >> --
> >> livecd mailing list
> >> 
> >> livecd(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/livecd
> > 
> > --
> > livecd mailing list
> > livecd(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/livecd
>  
>  --
>  livecd mailing list
>  livecd(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/livecd

[James Heather]

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(a)lists.fedoraproject.org
>  >>> 
>  >>>>> 
>  >>> https://admin.fedoraproject.org/mailman/listinfo/livecd
>  >>> 
>  >>>> 
>  >>>> --
>  >>>> livecd mailing list
>  >>>> 
>  >>> livecd(a)lists.fedoraproject.org
>  >>> 
>  >>>> 
>  >>> https://admin.fedoraproject.org/mailman/listinfo/livecd
>  >>> 
>  >>> 
>  >>> 
>  >>> --
>  >>> livecd mailing list
>  >>> 
>  >>> livecd(a)lists.fedoraproject.org
>  >>> https://admin.fedoraproject.org/mailman/listinfo/livecd
>  >> 
>  >> --
>  >> livecd mailing list
>  >> livecd(a)lists.fedoraproject.org
>  >> https://admin.fedoraproject.org/mailman/listinfo/livecd
>  > 
>  > --
>  > livecd mailing list
>  > livecd(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/livecd
>  
>  --
>  livecd mailing list
>  livecd(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/livecd

[Mr Dash Four]

>  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?
>     
This is what I do to, ironically, include a custom-built nouveau driver 
*into* the initramfs image as the one shipped with the Fedora kernel is 
not synced with the dev branch of nouveau, so I have to built the driver 
and integrate it into initramfs separately. The process below shouldn't 
be much different if you wish to remove nouveau completely:

update initramfs
~~~~~~~~~~~~~~~~
(as root in bash)
export __ver=2.40.6-0
export __dist=fc13
export __arch=x86_64
cd ~
mkdir temp
cp /boot/initramfs-$__ver.$__dist.$__arch.img temp/
cd temp
mv initramfs-$__ver.$__dist.$__arch.img initramfs-$__ver.$__dist.$__arch.gz
gunzip initramfs-$__ver.$__dist.$__arch.gz
mkdir contents
cd contents/
cpio -id < ../initramfs-$__ver.$__dist.$__arch
# do your modifications here
find ./ | cpio -H newc -o > ../initramfs-$__ver.$__dist.$__arch
cd ..
gzip -9 < initramfs-$__ver.$__dist.$__arch > 
initramfs-$__ver.$__dist.$__arch.img
cp /boot/initramfs-$__ver.$__dist.$__arch.img 
/boot/initramfs-$__ver.$__dist.$__arch.last.img
mv initramfs-$__ver.$__dist.$__arch.img /boot/

A note of caution - the nouveau driver is in /lib/modules/<kernel>/... 
as well as initramfs, so if you want to remove it you need to do it in 
both places - /lib/modules/<kernel> as well as initramfs as shown above. 
I am using 2.6.40.6 (3.0.6) version of the kernel on fc13 system, but 
the above process shouldn't be very different for your distro. Hope this 
helps.

[Bruno Wolff III]

On Tue, Oct 25, 2011 at 10:50:09 +0100,
  Tim Coote <tim+fedoraproject.org(a)coote.org&gt; 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? 
I am not sure if the overlay for / will work for /home. There is another option
to provide an area for a persistent /home.

[Tim Coote]

Thanks, Bruno. But it's the persistent / that I want.
On 25 Oct 2011, at 13:22, Bruno Wolff III wrote:

>  On Tue, Oct 25, 2011 at 10:50:09 +0100,
>   Tim Coote <tim+fedoraproject.org(a)coote.org&gt; 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?
>  
>  I am not sure if the overlay for / will work for /home. There is another option
>  to provide an area for a persistent /home.