HI =)

First I would like to very thank you, the author of this wonderful distro, now I can use my favourite OS on my USB stick

I successfully installed it on my sda1, sda2 is used for personal docs =) And I must say that the option to use the liveCD to boot the usb stick was necessary for me, else none of any other distro would make me able to boot (my bios seems to be a bit deprecated, it has all the options but it can't boot, it just freeze when usb boot is detected :/).

I successfully customized my MCNLive with a persistent loop, with installing nvidia drivers and 3D Desktop
I know this is an experimental feature, but I need it.

But now, I'm wondering if this loop can damage my usb stick as quickly as it has been said in the MCNLive website about other methods used in other LiveOS, because I can't find anywhere any informations on how the persistent loop works in MCNLive. And if it can damage because it writes frequently on the USB stick, do I have some alternative to only read the configuration in the loop without modify it (because now everything is configured I don't need to write in) ?

Thank's in advance for any answer =)

/EDIT: Last question: is there a way to know how much free space is left inside the loopback file, and if there is a way to resize it ?

Hi grosbedo

glad that you like our little baby.

Your questions.

1. I don't think that the persistent loop file will damage your usb stick. We went for a 'loop file' ( and not for a real directory like other live distros do) on the stick to make it efficient. Inside this loop file you have a linux ext2 filesystem which is a non-journalized FS. If you have a stick -let's say- not older than two years, you should be safe. Meanwhile the quality of the flash drives are pretty good. Some manufacturers even say that no matter how many writes are made, the stick will survive 10 years. Ah well.
But you never know ...

2. If you have everything configured, you are prettysafe anyway. It won't write much. Most things in a live system happen in memory, not on a real device. What you can do to reduce the write access is, when you save personal documents or video or music files, don't save them in /home/guest, but store them somewhere on a real device, the internal hard disk or the real partition on the usb stick. This way they don't get included in the loop file :-)
Also, we did take care when making mcnlive that for example in web browsers the cache is disabled, and it won't get saved.

3. There is a way to resize the loop file, but we have did not make any tests so far. Also, I need to find out what the command is to see the used space.

Oops. This answer is kind of not correct. Re-sizing would mean that you 'd loose all saved changes.
This does not make sense, or? It is easier to just delete the file (when you don't boot with the persist bootcode) and create a new loop with the wizard.

To see how much is used. Pretty easy. When you boot without the 'livecd persist', then plug in the stick.
Click on the 'devices' icon on the desktop, click on the symbol for the stick. Now it is mounted somewhere. Find out by typing: mount in a terminal. You should see the partition(s). Where is your mcnlive.loop? On the first partition?

Example it is mounted at the mountpoint /media/removable

In a terminal:



You first create a mountpoint (mkdir /mnt/test), then you mount the loop file, the df command will give you the used size, then you umount the loop and you exit 'root'.

When you run MCNLive with 'livecd persist' it should be possible to just do:

Thank you very much for these quick answers.

1) But to precise my configuration, the loop file is on the same hardware than the os, meaning the USB stick (I must have it everywhere I go because I'll use it for personal AND professional, and I will make you some publicity too by the way of course ;p), and in your website that's what is written:



And from what I've (little) studied about the subject, flash memory isn't designed to have unlimited write-cycles, it's inherent to the system. None hardware have infinite lifetime, but flash seems to not be designed for an extended use of the write function, but is mainly focused on reading use. But my last informations date back from some years ago, so it may have changed.
Anyway it seems the problem is to write inside the file continuously, so that's why I'm asking if it uses a really different method that limit disk usage, or not :/ In which case I will find a way around (but it would be a nice feature for next realse if it's possible, read-only loopback file).

And sadly, I highly doubt that it could be used while 10 years in these conditions, while a simple CD-ROM can barely last this long while being read-only (after the first writing I mean).

Anyway I will test, I just wanted to know if there was some alternatives, but I'll find my way about that =)

2) Thank's for advice, I figured it out after some hours of tests

3) By resizing, I mean enlarge it if in the future I get a new usb key, or if I find another bigger storage place for the loop file. But if it is possible to mount it as a filesystem it may be possible to resize it like a partition, am I wrong ? =)
And thx Kris, I can't test it right now but I'm sure it will be OK, I didn't think it was possible to read this file so easily with conventional methods

4) (I know there aren't 4 but I like to innovate ) I saw that you needed feedback about this feature, and since I tested for multiple hours today I will list you some bugs I found (beside the unmount loop bug at logout):
a. When the OS freeze (happens sometimes simply when a software freeze), it's impossible to terminate the session or call the taskmanager.
b. Some rpm simply won't install. It will download and install all dependancies, but when it comes to the software you want, it freezes at the middle of the install. Then the OS freeze and you come to bug a, you must hard reboot (or if you have the luck to be able to shutdown the konsole or mcc, if you logout it will put you on shell login screen, then you will have to type "halt" to shutdown). The workaround I found for this bug: download the software rpm myself (after installing dependancies with urpmi and reboot because of bug), then it will in MOST CASES install without any flaw (amongst 15 softs I installed this way 1 didn't work, but I'm sure with another version of the package it would work). I verified and it seems not a matter of place (in the loop and RAM).
c. When you install many softwares in the loop, you must wait some minutes when you boot, else you have great chances to meet some weird bugs (like a software that launches fullscreen but is invisible, but you hear the sound, and it's impossible to do anything except hard reboot).

That's all I found for the moment. I dunno if these bugs comes from MCNLive loop or from the fact that its live and runs mainly on RAM.

Anyway I must admit I have a little hardtested, I have configured Beryl with almost all options with NVidia card drivers, I tested reading a commercial DVD with xine while transferring 3 files in 3 differents locations from 3 different sources, and with amarok playing music with crossfade and I was playing with transparency and zoom with the windows, and everything was running smooth (sometimes there was some glitches but its normal). The only noticeable thing was there was a latency in the focusing of Beryl on the windows (it automatically put transparent the windows that are in front of the one where my cursor is).
I tested to play some 3D game too, with OpenArena v0.60 on my second partition of the USB stick (from sources, else with rpm it would have gone into the loopfile which I can't afford), and I was surprising to be able to play it with all my usual settings, and with high (120) FPS.

So your loopfile is very functional, and if it really can't damage the USB flash memory it would be perfect ! =D
I'll add some other feedbacks if I find other bugs =)

Thank you for your feedback, very much appreciated. It is our first version with the persistent changes feature, and every feedback reg. issues and problems are important.

My website with the warning about the limited life of flash memory is based on my knowledge from 2005 when we made the first live usb edition. Meanwhile more and more information just state that the quality and the technology improved - well, I am not sure, of course.
What we did is, we used the same techniques as Mandriva Flash -- and they gave a warranty of 5 years on the hardware = the usb stick, and I thought, hmm, not bad.
Also, I excluded some default writings, for example /tmp and some /var sub dirs -- so the write cycles are not so excessive.

The resizing stuff. The problem is not to resize a real partition, but an image disk made with dd, which afterwards is formatted as a ext2 FS. I need to find out more, if it is possible or not.
For the time being the easiest way is to create a new larger file, mount the old file and copy all stuff over into the new mcnlive.loop :-P

Freezing/hanging looks like a RAM problem, indeed.



Ah, seems that we need to wait until everything is synced on the usb device.



Please do !!

I don't know if this helps: http://lkml.org/lkml/2006/5/23/26

Or this: http://jailtime.org/howto:start

Is it true for all web browsers or only for the default ones (Konqueror and Opera) ?
I've managed to installed firefox but now I'm wondering if the continuous cache writing will alter ma usb disk

If you installed Firefox yourself, then the default setting for Firefox would be that caching is on, and it would indeed be a good idea to turn that off on your live-usb

thanks a lot
to do it, I only need to set the cache size to 0 MB or is there another method ?