My laptop runs Mandriva, but because I do end-user support for both Mandriva and Fedora issues I'd like to have both systems. Unfortunately I simply don't have enough drive space to install another OS, so I wondered whether I could actually install F9 onto an 8GB usb stick.
I've read http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo and http://www.redhatmagazine.com/2007/11/07/i-am-fedora-and-so-can-you/, but these seem to refer to a non-upgradable system. Since I need to be able to use KDE 4.1 that won't suffice.
Can anyone please point me to useful reading, or give a brief rundown of tasks and things to remember in doing this?
Thanks
Anne
Anne Wilson wrote:
My laptop runs Mandriva, but because I do end-user support for both Mandriva and Fedora issues I'd like to have both systems. Unfortunately I simply don't have enough drive space to install another OS, so I wondered whether I could actually install F9 onto an 8GB usb stick.
I've read http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo and http://www.redhatmagazine.com/2007/11/07/i-am-fedora-and-so-can-you/, but these seem to refer to a non-upgradable system. Since I need to be able to use KDE 4.1 that won't suffice.
Can anyone please point me to useful reading, or give a brief rundown of tasks and things to remember in doing this?
The USB howto will work fine. You can currently upgrade everything on the USB key except the kernel IIRC. It is really no different from running off a hard disk other than the fact that it is more portable.
Rahul
On Sunday 03 August 2008 12:49:10 Rahul Sundaram wrote:
Anne Wilson wrote:
My laptop runs Mandriva, but because I do end-user support for both Mandriva and Fedora issues I'd like to have both systems. Unfortunately I simply don't have enough drive space to install another OS, so I wondered whether I could actually install F9 onto an 8GB usb stick.
I've read http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo and http://www.redhatmagazine.com/2007/11/07/i-am-fedora-and-so-can-you/, but these seem to refer to a non-upgradable system. Since I need to be able to use KDE 4.1 that won't suffice.
Can anyone please point me to useful reading, or give a brief rundown of tasks and things to remember in doing this?
The USB howto will work fine. You can currently upgrade everything on the USB key except the kernel IIRC. It is really no different from running off a hard disk other than the fact that it is more portable.
Thanks, Rahul. That's really good to know. I'll give it a try.
Anne
On Sun, Aug 3, 2008 at 7:49 AM, Rahul Sundaram sundaram@fedoraproject.orgwrote:
Anne Wilson wrote:
My laptop runs Mandriva, but because I do end-user support for both Mandriva and Fedora issues I'd like to have both systems. Unfortunately I simply don't have enough drive space to install another OS, so I wondered whether I could actually install F9 onto an 8GB usb stick.
I've read http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo and http://www.redhatmagazine.com/2007/11/07/i-am-fedora-and-so-can-you/, but these seem to refer to a non-upgradable system. Since I need to be able to use KDE 4.1 that won't suffice.
Can anyone please point me to useful reading, or give a brief rundown of tasks and things to remember in doing this?
The USB howto will work fine. You can currently upgrade everything on the USB key except the kernel IIRC. It is really no different from running off a hard disk other than the fact that it is more portable.
Rahul
This has not been my experience. I was actually able to update the kernel without problem but several other packages have caused problems, most notably udev which had an issue during reboot with an error about loading the 50-udev-default.rules.
I've also had problems with updating xorg. X tried and failed to load, but instead of only trying 3 times it went into an infinite loop.
Also, after reading a previous post on this list, I would keep updates to only things you care about since the overlay file records block changes and you will eventually run out of overlay.
My HW if anyone is interested: HP 8510w (Laptop workstation) Core2Duo (2.4GHz) Centrino vPro chipset. Nvidia Quadro 256MB
Richard
Richard Shaw wrote:
This has not been my experience. I was actually able to update the kernel without problem but several other packages have caused problems, most notably udev which had an issue during reboot with an error about loading the 50-udev-default.rules.
I've also had problems with updating xorg. X tried and failed to load, but instead of only trying 3 times it went into an infinite loop.
Did you ever file any bug reports?
Rahul
On Sun, Aug 3, 2008 at 8:42 AM, Rahul Sundaram sundaram@fedoraproject.orgwrote:
Richard Shaw wrote:
This has not been my experience. I was actually able to update the kernel without problem but several other packages have caused problems, most notably udev which had an issue during reboot with an error about loading the 50-udev-default.rules.
I've also had problems with updating xorg. X tried and failed to load, but instead of only trying 3 times it went into an infinite loop.
Did you ever file any bug reports?
Rahul
Not yet, I just recently subscribed to this list so I could find out if a liveusb system was supposed to be fully updateable or not.
Richard
On Sunday 03 August 2008 13:34:20 Richard Shaw wrote:
On Sun, Aug 3, 2008 at 7:49 AM, Rahul Sundaram
sundaram@fedoraproject.orgwrote:
Anne Wilson wrote:
My laptop runs Mandriva, but because I do end-user support for both Mandriva and Fedora issues I'd like to have both systems. Unfortunately I simply don't have enough drive space to install another OS, so I wondered whether I could actually install F9 onto an 8GB usb stick.
I've read http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo and http://www.redhatmagazine.com/2007/11/07/i-am-fedora-and-so-can-you/, but these seem to refer to a non-upgradable system. Since I need to be able to use KDE 4.1 that won't suffice.
Can anyone please point me to useful reading, or give a brief rundown of tasks and things to remember in doing this?
The USB howto will work fine. You can currently upgrade everything on the USB key except the kernel IIRC. It is really no different from running off a hard disk other than the fact that it is more portable.
Rahul
This has not been my experience. I was actually able to update the kernel without problem but several other packages have caused problems, most notably udev which had an issue during reboot with an error about loading the 50-udev-default.rules.
I've also had problems with updating xorg. X tried and failed to load, but instead of only trying 3 times it went into an infinite loop.
Also, after reading a previous post on this list, I would keep updates to only things you care about since the overlay file records block changes and you will eventually run out of overlay.
My HW if anyone is interested: HP 8510w (Laptop workstation) Core2Duo (2.4GHz) Centrino vPro chipset. Nvidia Quadro 256MB
Richard
Ah yes - the overlay. I'm not sure that I more than half understand it, but if I do, that could be a problem. The LiveCD will be KDE 4.0 (probably 4.0.3) and I need 4.1, so there would be a huge amount to update. What would be the best chance of dealing with that?
Anne
On Sun, 2008-08-03 at 08:34 -0400, Richard Shaw wrote:
This has not been my experience. I was actually able to update the kernel without problem but several other packages have caused problems, most notably udev which had an issue during reboot with an error about loading the 50-udev-default.rules.
This got filed relatively recently and fixed up. For F9-based images, though, you'll have to do a workaround of removing the /etc/udev/rules.d/50-udev-default.rules.rpm* (or at least, move them out of the way)
I've also had problems with updating xorg. X tried and failed to load, but instead of only trying 3 times it went into an infinite loop.
That sounds like something more general and not live image specific. It'd be worth getting a ctrl-alt-delete in there to reboot and then boot into runlevel 3 so you could grab some logs to file against X
Also, after reading a previous post on this list, I would keep updates to only things you care about since the overlay file records block changes and you will eventually run out of overlay.
This is the case and unfortunately, with things currently in the kernel, I don't really see any way around it. Modulo writing some tool to (likely offline) analyze and rewrite the snapshot file. But relatively deep dark voodoo required to write such a tool
Jeremy
On Mon, Aug 4, 2008 at 7:54 AM, Jeremy Katz katzj@redhat.com wrote:
On Sun, 2008-08-03 at 08:34 -0400, Richard Shaw wrote:
This has not been my experience. I was actually able to update the kernel without problem but several other packages have caused problems, most notably udev which had an issue during reboot with an error about loading the 50-udev-default.rules.
This got filed relatively recently and fixed up. For F9-based images, though, you'll have to do a workaround of removing the /etc/udev/rules.d/50-udev-default.rules.rpm* (or at least, move them out of the way)
I did rename it but forgot that the * gets it anyway...
I've also had problems with updating xorg. X tried and failed to load, but instead of only trying 3 times it went into an infinite loop.
That sounds like something more general and not live image specific. It'd be worth getting a ctrl-alt-delete in there to reboot and then boot into runlevel 3 so you could grab some logs to file against X
I'll do that. I remember one of the errors I saw while it flashed by was something about AIGLX.
Also, after reading a previous post on this list, I would keep updates to only things you care about since the overlay file records block changes and you will eventually run out of overlay.
This is the case and unfortunately, with things currently in the kernel, I don't really see any way around it. Modulo writing some tool to (likely offline) analyze and rewrite the snapshot file. But relatively deep dark voodoo required to write such a tool
Jeremy
I don't know if this would be easier, but what about a tool that would incorporate the changes back into the image file and then re-zero the overlay?
Richard
On Mon, 2008-08-04 at 08:43 -0500, Richard Shaw wrote:
On Mon, Aug 4, 2008 at 7:54 AM, Jeremy Katz katzj@redhat.com wrote:
Also, after reading a previous post on this list, I would keep updates to only things you care about since the overlay file records block changes and you will eventually run out of overlay.
This is the case and unfortunately, with things currently in the kernel, I don't really see any way around it. Modulo writing some tool to (likely offline) analyze and rewrite the snapshot file. But relatively deep dark voodoo required to write such a tool
I don't know if this would be easier, but what about a tool that would incorporate the changes back into the image file and then re-zero the overlay?
The problem is that incorporating the changes back in basically boils down to "make a new image". Which isn't that difficult to do, it's just a matter of having the disk space for it and also the time -- it'd largely just be a matter of running good chunks of the livecd image creation process over again.
Jeremy
On Mon, Aug 4, 2008 at 8:51 AM, Jeremy Katz katzj@redhat.com wrote:
On Mon, 2008-08-04 at 08:43 -0500, Richard Shaw wrote:
On Mon, Aug 4, 2008 at 7:54 AM, Jeremy Katz katzj@redhat.com wrote:
Also, after reading a previous post on this list, I would keep updates to only things you care about since the overlay file records block changes and you will eventually run out of overlay.
This is the case and unfortunately, with things currently in the
kernel,
I don't really see any way around it. Modulo writing some tool to (likely offline) analyze and rewrite the snapshot file. But relatively deep dark voodoo required to write such a tool
I don't know if this would be easier, but what about a tool that would incorporate the changes back into the image file and then re-zero the overlay?
The problem is that incorporating the changes back in basically boils down to "make a new image". Which isn't that difficult to do, it's just a matter of having the disk space for it and also the time -- it'd largely just be a matter of running good chunks of the livecd image creation process over again.
Jeremy
Well, I don't know about other users of the live USB system, but that would
be okay with me. A prereq. would be you have enough HD space to copy the image, update it, and then copy it back to the USB drive.
Richard
Richard Shaw wrote:
On Mon, Aug 4, 2008 at 8:51 AM, Jeremy Katz <katzj@redhat.com
The problem is that incorporating the changes back in basically boils down to "make a new image". Which isn't that difficult to do, it's just a matter of having the disk space for it and also the time -- it'd largely just be a matter of running good chunks of the livecd image creation process over again. Jeremy
Well, I don't know about other users of the live USB system, but that would be okay with me. A prereq. would be you have enough HD space to copy the image, update it, and then copy it back to the USB drive.
FYI I outlined the process here-
https://www.redhat.com/archives/fedora-livecd-list/2008-June/msg00024.html
-dmc
On Monday 04 August 2008 13:54:30 Jeremy Katz wrote:
This got filed relatively recently and fixed up. For F9-based images, though, you'll have to do a workaround of removing the /etc/udev/rules.d/50-udev-default.rules.rpm* (or at least, move them out of the way)
I thought I was almost there. I gave it an overlay of 6533 MB, got it booted and running on the EeePC, then started the big update. Unfortunately that took so long that the battery ran out while I was away from it. There could be packages still in the cache to be installed, but I can't move about at all. I have a bash prompt but it doesn't recognise basic bash commands such as cd and mv.
It's clear from the warning message I got that I do need to do the workaround mentioned above.
Any advice on how to proceed?
Anne
On Monday 04 August 2008 18:48:44 Anne Wilson wrote:
On Monday 04 August 2008 13:54:30 Jeremy Katz wrote:
This got filed relatively recently and fixed up. For F9-based images, though, you'll have to do a workaround of removing the /etc/udev/rules.d/50-udev-default.rules.rpm* (or at least, move them out of the way)
I thought I was almost there. I gave it an overlay of 6533 MB, got it booted and running on the EeePC, then started the big update. Unfortunately that took so long that the battery ran out while I was away from it. There could be packages still in the cache to be installed, but I can't move about at all. I have a bash prompt but it doesn't recognise basic bash commands such as cd and mv.
It's clear from the warning message I got that I do need to do the workaround mentioned above.
Any advice on how to proceed?
I now have the exact messages in front of me:
usb 2-1: device not accepting address 2, error -71 sd 2:0:0:0: [sdb] Assuming drive cache: write through sd 2:0:0:0: [sdb] Assuming drive cache: write through /init: line 478: /sysroot/etc/udev/rules.d/50-udev*: ambiguous redirect Bug in initramfs /init detected. Dropping to a shell. Good luck!
(by which I guess it means I'll need it :-) )
The prompt says bash-3.2#
and doesn't recognise commands.
Anne
On Mon, Aug 4, 2008 at 1:31 PM, Anne Wilson cannewilson@googlemail.comwrote:
On Monday 04 August 2008 18:48:44 Anne Wilson wrote:
On Monday 04 August 2008 13:54:30 Jeremy Katz wrote:
This got filed relatively recently and fixed up. For F9-based images, though, you'll have to do a workaround of removing the /etc/udev/rules.d/50-udev-default.rules.rpm* (or at least, move
them
out of the way)
I thought I was almost there. I gave it an overlay of 6533 MB, got it booted and running on the EeePC, then started the big update. Unfortunately that took so long that the battery ran out while I was away from it. There could be packages still in the cache to be installed, but
I
can't move about at all. I have a bash prompt but it doesn't recognise basic bash commands such as cd and mv.
It's clear from the warning message I got that I do need to do the workaround mentioned above.
Any advice on how to proceed?
I now have the exact messages in front of me:
usb 2-1: device not accepting address 2, error -71 sd 2:0:0:0: [sdb] Assuming drive cache: write through sd 2:0:0:0: [sdb] Assuming drive cache: write through /init: line 478: /sysroot/etc/udev/rules.d/50-udev*: ambiguous redirect Bug in initramfs /init detected. Dropping to a shell. Good luck!
(by which I guess it means I'll need it :-) )
The prompt says bash-3.2#
and doesn't recognise commands.
Anne
Go into /etc/udev/rules.d/ and delete the extra file with the rpmsave or rpmnew.
Richard
On Monday 04 August 2008 21:20:18 Richard Shaw wrote:
On Mon, Aug 4, 2008 at 1:31 PM, Anne Wilson
cannewilson@googlemail.comwrote:
On Monday 04 August 2008 18:48:44 Anne Wilson wrote:
On Monday 04 August 2008 13:54:30 Jeremy Katz wrote:
This got filed relatively recently and fixed up. For F9-based images, though, you'll have to do a workaround of removing the /etc/udev/rules.d/50-udev-default.rules.rpm* (or at least, move
them
out of the way)
I thought I was almost there. I gave it an overlay of 6533 MB, got it booted and running on the EeePC, then started the big update. Unfortunately that took so long that the battery ran out while I was away from it. There could be packages still in the cache to be installed, but
I
can't move about at all. I have a bash prompt but it doesn't recognise basic bash commands such as cd and mv.
It's clear from the warning message I got that I do need to do the workaround mentioned above.
Any advice on how to proceed?
I now have the exact messages in front of me:
usb 2-1: device not accepting address 2, error -71 sd 2:0:0:0: [sdb] Assuming drive cache: write through sd 2:0:0:0: [sdb] Assuming drive cache: write through /init: line 478: /sysroot/etc/udev/rules.d/50-udev*: ambiguous redirect Bug in initramfs /init detected. Dropping to a shell. Good luck!
(by which I guess it means I'll need it :-) )
The prompt says bash-3.2#
and doesn't recognise commands.
Anne
Go into /etc/udev/rules.d/ and delete the extra file with the rpmsave or rpmnew.
Richard
I can't Richard. It doesn't recognise any commands, and the file system isn't accessible if I boot from the hard drive.
Anne
On Mon, Aug 4, 2008 at 4:01 PM, Anne Wilson cannewilson@googlemail.comwrote:
On Monday 04 August 2008 21:20:18 Richard Shaw wrote:
On Mon, Aug 4, 2008 at 1:31 PM, Anne Wilson
cannewilson@googlemail.comwrote:
On Monday 04 August 2008 18:48:44 Anne Wilson wrote:
On Monday 04 August 2008 13:54:30 Jeremy Katz wrote:
This got filed relatively recently and fixed up. For F9-based images, though, you'll have to do a workaround of removing the /etc/udev/rules.d/50-udev-default.rules.rpm* (or at least, move
them
out of the way)
I thought I was almost there. I gave it an overlay of 6533 MB, got
it
booted and running on the EeePC, then started the big update. Unfortunately that took so long that the battery ran out while I was away from it. There could be packages still in the cache to be installed, but
I
can't move about at all. I have a bash prompt but it doesn't recognise basic bash commands such as cd and mv.
It's clear from the warning message I got that I do need to do the workaround mentioned above.
Any advice on how to proceed?
I now have the exact messages in front of me:
usb 2-1: device not accepting address 2, error -71 sd 2:0:0:0: [sdb] Assuming drive cache: write through sd 2:0:0:0: [sdb] Assuming drive cache: write through /init: line 478: /sysroot/etc/udev/rules.d/50-udev*: ambiguous redirect Bug in initramfs /init detected. Dropping to a shell. Good luck!
(by which I guess it means I'll need it :-) )
The prompt says bash-3.2#
and doesn't recognise commands.
Anne
Go into /etc/udev/rules.d/ and delete the extra file with the rpmsave or rpmnew.
Richard
I can't Richard. It doesn't recognise any commands, and the file system isn't accessible if I boot from the hard drive.
Anne
You'll have to rezero your overlay file and start over then... You can do it manually from a windows or linux box but the dd command is a little different for each. On a linux box it's something like:
dd if=/dev/zero of=/mount/path/LiveOS/overlay-{LABEL}-{UUID} bs=1M count={size of overlay in MB}
Or on windows (the dd.exe is located under tools in the liveusb-creator directory)
dd.exe if=/dev/zero of={drive letter}:\LiveOS\overlay-{LABEL}-{UUID} bs=1M count={size of overlay in MB}
Just look at the current name of your overlay file and overwrite it rather than looking up the LABEL and UUID.
I, like others, have created an extra entry in my syslinx.cfg without the overlay option just in case I hose my overlay file and still want to be able to use it.
Richard
On Monday 04 August 2008 23:06:16 Richard Shaw wrote:
I can't Richard. It doesn't recognise any commands, and the file system isn't accessible if I boot from the hard drive.
Anne
You'll have to rezero your overlay file and start over then... You can do it manually from a windows or linux box but the dd command is a little different for each. On a linux box it's something like:
dd if=/dev/zero of=/mount/path/LiveOS/overlay-{LABEL}-{UUID} bs=1M count={size of overlay in MB}
Or on windows (the dd.exe is located under tools in the liveusb-creator directory)
dd.exe if=/dev/zero of={drive letter}:\LiveOS\overlay-{LABEL}-{UUID} bs=1M count={size of overlay in MB}
Just look at the current name of your overlay file and overwrite it rather than looking up the LABEL and UUID.
I, like others, have created an extra entry in my syslinx.cfg without the overlay option just in case I hose my overlay file and still want to be able to use it.
Hi, Richard. I decided that I might as well start again from the beginning :-)
The install seems to go well enough, as does the update, right to the very end. I glanced at the screen when it had about 5 packages still to go in the cleanup, but the next time I looked it said:
File "usr/lib/python2.5/site-packages/dbus/connection.py", line 597, in call_blocking message.append(signature=signature, *args) TypeError: More items found in D-Bus signature than in Python arguments.
Is this a big problem?
I had removed /etc/udev/rules.d/50-udev-default.rules, but I see it has been created again. This time there is also a 50-udev.nodes. Do I delete both of these?
Anything else I need to deal with before attempting a reboot?
Anne
On Tue, Aug 5, 2008 at 6:51 AM, Anne Wilson cannewilson@googlemail.comwrote:
On Monday 04 August 2008 23:06:16 Richard Shaw wrote:
I can't Richard. It doesn't recognise any commands, and the file
system
isn't accessible if I boot from the hard drive.
Anne
You'll have to rezero your overlay file and start over then... You can do it manually from a windows or linux box but the dd command is a little different for each. On a linux box it's something like:
dd if=/dev/zero of=/mount/path/LiveOS/overlay-{LABEL}-{UUID} bs=1M count={size of overlay in MB}
Or on windows (the dd.exe is located under tools in the liveusb-creator directory)
dd.exe if=/dev/zero of={drive letter}:\LiveOS\overlay-{LABEL}-{UUID}
bs=1M
count={size of overlay in MB}
Just look at the current name of your overlay file and overwrite it
rather
than looking up the LABEL and UUID.
I, like others, have created an extra entry in my syslinx.cfg without the overlay option just in case I hose my overlay file and still want to be able to use it.
Hi, Richard. I decided that I might as well start again from the beginning :-)
The install seems to go well enough, as does the update, right to the very end. I glanced at the screen when it had about 5 packages still to go in the cleanup, but the next time I looked it said:
File "usr/lib/python2.5/site-packages/dbus/connection.py", line 597, in call_blocking message.append(signature=signature, *args) TypeError: More items found in D-Bus signature than in Python arguments.
Is this a big problem?
I've never seen that one before.
I had removed /etc/udev/rules.d/50-udev-default.rules, but I see it has been created again. This time there is also a 50-udev.nodes. Do I delete both of these?
Anything else I need to deal with before attempting a reboot?
Anne
I probably should have chosen my words more carefully. I believe you want one file called 50-udev-default.rules, but when yum updates the udev package it chooses to not overwrite the existing file and instead creates a file called 50-udev-default.rules.rpmnew. Unfortunately, it appears that udev requests all files called 50-udev-default* or something like that and finds two matching files. Since it doesn't know which one to choose it choses neither and dumps you to a bash shell.
This is what I have inferred from it. There are seveal on this list that know more about udev than I.
Richard
On Tuesday 05 August 2008 13:51:27 Richard Shaw wrote:
I probably should have chosen my words more carefully. I believe you want one file called 50-udev-default.rules, but when yum updates the udev package it chooses to not overwrite the existing file and instead creates a file called 50-udev-default.rules.rpmnew. Unfortunately, it appears that udev requests all files called 50-udev-default* or something like that and finds two matching files. Since it doesn't know which one to choose it choses neither and dumps you to a bash shell.
This is what I have inferred from it. There are seveal on this list that know more about udev than I.
OK - I checked for rpmnew files and made appropriate decisions. I now have 4.1 running nicely :-) with my first folderview :-). The only thing left to do is sort out NetworkManager, ready for wifi access.
Thanks for the help and patience.
Anne
On Sun, 2008-08-03 at 12:18 +0100, Anne Wilson wrote:
My laptop runs Mandriva, but because I do end-user support for both Mandriva and Fedora issues I'd like to have both systems. Unfortunately I simply don't have enough drive space to install another OS, so I wondered whether I could actually install F9 onto an 8GB usb stick.
I've read http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo and http://www.redhatmagazine.com/2007/11/07/i-am-fedora-and-so-can-you/, but these seem to refer to a non-upgradable system. Since I need to be able to use KDE 4.1 that won't suffice.
You can do updates -- the only things are 1) Consistently updating will require significant amounts of space within the writable overlay. And the amount of space required will increase over time -- dm-snapshot will never again write to a block after it's done so once 2) Updating the kernel can't really be done without some manual steps right now 3) There may be some slight caveats like the one mentioned by Richard Shaw later in the thread as F9 is the first release where this has really been possible.
Jeremy
Jeremy Katz wrote:
On Sun, 2008-08-03 at 12:18 +0100, Anne Wilson wrote:
My laptop runs Mandriva, but because I do end-user support for both Mandriva and Fedora issues I'd like to have both systems. Unfortunately I simply don't have enough drive space to install another OS, so I wondered whether I could actually install F9 onto an 8GB usb stick.
I've read http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo and http://www.redhatmagazine.com/2007/11/07/i-am-fedora-and-so-can-you/, but these seem to refer to a non-upgradable system. Since I need to be able to use KDE 4.1 that won't suffice.
You can do updates -- the only things are
- Consistently updating will require significant amounts of space
within the writable overlay. And the amount of space required will increase over time -- dm-snapshot will never again write to a block after it's done so once
Never say never. Or at least, not in this case. If you find a way to swing a 4G overlay for an f9 system, you will never run out of overlay space.
The problem is that with reasonable sized overlay files, the likelyhood of blocks getting reused is small.
-dmc
livecd@lists.fedoraproject.org