Please ignore this post and read on to the next. This one is outdated
Just uploaded FreevoLive 0.10!!

Please feel free to download it, at http://freevolive.tuxfamily.org


What's new?
The main difference is that the display is now set to SDL, which makes TV and videos finally display at full screen
Besides that, I installed Freevo 1.6.3, from Korrel's test-rpm, and I added a few setterm lines in .bash_profile, to stop the screen from blanking, and remove the flickering cursor on the screen.

Must say many thanks to David pointing me to the setterm lines


Known issues
- Some, or maybe a lot of, tv cards won't work because there not autodetected by harddrake
- KDE crashes after a few minutes, I think this is due to a bug in Freevo's commands plugin


Testers wanted!
Well, I would like to know if it works for you, and if not, what doesn't work.
I'd like to know if the switch to SDL video is giving any problems.

I'm still interested in people with a saa713x TV card, but I would also like to know what more TV cards we can try to enable within the same script

If you have any ideas on how to improve this remaster, please share it!

Well, actually, ignore this one too
FreevoLive 0.13 is out now!

Yesterday, I've uploaded FreevoLive 0.11!


Whats new?
- Uninstalled Freevo 1.6.3 and python-mm
- Installed Freevo 1.7.0 and the kaa-packages (thanks to Korrel for the rpms!)
- Kernel 2.6.17.11mdv
- Added appletrailers plugin
- Added a new bootsplash, with the new MCNLive logo [example]


New problems?
Yep, though not very big ones. Somehow, audio album covers aren't shown.


That's all?
Yeah, I tried to do some more, but ran into some issues, so I didn't have enough time to fix anything.
I wanted to have a version with Freevo 1.7.0 though, so in the next version I'll try to fix (some of the) known issues.

I did remove the 'exit' at the end of .bash_profile though, to be able to do some more debugging without having to start a new session.

I've tested 0.11.

Small isssues, easy to fix:

* Menu -> Office -> Communications --> Fax
--> dooes not exist

* Menu -> Internet -> Filetransfer -> kasablanca
--> does not exist

Button on the dsktop: Switch language --> there is nothing to switch

* Directory: /home/guest/.opera
--> can be cleaned/erased

X/KDE still crashes.
Is it possible that there are two freevo processes/scripts running in runlevel 5: record server and webserver?
Why do they run? What are they doing with X/KDE?
If I am not mistaken, in an earlier version both services did not run, (we had an error message that they are not running) and there was no X crash.
Is the default runlevel: 3 ?

Didn't notice that...

W00P!

This one is not shown usually, so I didn't notice that as well

The default is indeed runlevel 3, because Freevo doesn't need X. So when KDE is ran from Freevo, it just issues the 'startx' command.
The X crash was there on .05 (the fist version I've made public), so this has nothing to do with the webserver and recordserver (which are just active since .08 and .09.

My guess is that it crashes only when run from Freevo, not when you just type 'startx' on a console, and this looks like a bug in the commands plugin. Other problem with this plugin, is that I cannot run any console programs with it (drakconf, mc, alsamixer, ...).
I'm trying to find a solution for this.

Other question: I updated the kernel, with urpmi to 2.6.17.11mdv, but there is still a madwifi kernel module for 2.6.17.5mdv on the system which I can't uninstall because it can't find dkms. Do you have any idea how to remove it, or maybe update it to work with the new kernel?

rpm -e --nodeps nameofpackage (without extension .rpm)
And delete the old kernel dir. You need to compile the madwifi modules for the new kernel.

I just made some more tests. Your default runlevel is not 3, but 5: in /etc/inittab
That means you are starting the xserver when starting freevo.

And how is freevo exactly started?
How is kde started? Which command? Which config file?

Why is there no login manager? KDM. KDM has a menu 'session': where you can exit to cli.

I still could not find a way to stop freevo and get to a console.
When i type 'h' I get a help menu without any useful hints.
How is an average user supposed to know? Also on this help page, you can read that one can type 'g' and would get a guide. But that does not work.

Suggestion:

Option 1- you want to keep KDE
1. start in init 3, no autologin
2. The user sees a short message, how to login, the command to start freevo, the command to start kde (startx)
3. If KDE is available, then this automated startup of Freevo instead of a real logout is really not nice.

Option 2: - Freevo pur, without KDE
With autologin etc.

Kris,

It does start at runlevel 3, but somehow, after boot, it always replaces the 3 in inittab with a 5. I have to edit this file manually before each remaster, or else both Freevo AND X are loaded. So you can switch between X and Freevo with CTRL + F1 and CTRL + F7.
I have no clue why this happens, but if I edit the file, and make it a 3 again before doing the remaster, everything is fine

You don't get a DM because I uninstalled it
You can stop Freevo, by selecting "Shutdown", and don't press Enter, but press the 'e' button on your keyboard, or the fourth button on your joystick if you have one connected. Then you'll get another menu, which enables you to shutdown Freevo, but not the whole system

Freevo is run from /home/guest/.bash_profile
KDE is started just with the command startx, and from Freevo from the file /home/guest/Commands/10-startx.fxd (which is just an xml file with the startx command in it, so Freevo understands it

Michel,

No! The whole system does start in init 5. You can see this in the start messages. It is init 5.
And I bet X is running.

(did you try to config it through MCC, or do you just edit inittab?)

Then you login the user guest at tty1 (by using inittab) - and my second bet is, that MDV does not honor it, starting in init 5 and autologin in tty1.

If you want autologin without a login manager you need to install the 'autologin' package.

It is also possible that a X server is already running when you perform: startx
( ... and the default tty is 7 for KDE)

I'll take a look at this. I just edit /etc/inittab, and haven't done anything with mcc.
But I'm pretty sure it runs in runlevel 3, or at least X-less, because when I don't edit inittab before doing the remaster, KDE is autostarted.

Besides that, I believe that it's just not possible to run X twice on a normal Mandriva system, AND someone told me that he could start X from outside Freevo, and do a complete install of FL to harddrive. You don't have enough time to complete the install when it's run from Freevo, so this must mean X does not crash when run from outside Freevo. But I'll have to take some time for this to figure out what exactly happens.

The -autologin option is just an option of the mingetty command.

Edit:
Just tried to install FreevoLive from a vmware-session. Somehow, it didn't crash, while X was run from Freevo, so X is not _always_ crashing (though it does most of the time).
Funny thing is, that the installed system still has 'id:3:initdefault:' in /etc/inittab.
As I said before, I have no clue why the 3 becomes a 5 on the live system after boot. The fact that the 3 is still a 3 on the installed system is even more strange

The only thing about X that I see starting during boot, is the X font server.
I believe you need this if you wish to use X, so I think I cannot disable it because that will break X completely.

This runlevel stuff is kind of weird.

Question: I hope you are not building the iso from within a VM, do you?

I do build it from a VM indeed, so I have no problems with cratched media, en don't have to burn every remaster
Is there a problem building it from a VM then?

Possible, yes. I am not sure.

Building a live cd from an installed system is better done from a real installation. In case you want to re-distribute it. For personal use: no problem.
There are people reporting other weird things if the base is a VM install. But I am very unfamiliar with it.
At least you need to reboot after changing the runlevel, there are some magic files saved somewhere in /var.

It is also possible that you have a remaster of the remaster of the an remaster and so on issue.

PS: you can 'build' the iso from a real installation, and do the 'testing' without burning, ie: in a VM.

Well, the first 5 remasters I did directly from an rewritable cd, and those had the same issues.
I have a VMware system, on which I load the iso as a bootable cd, and do a 'remaster on the fly'

Basically what you say is that it's a better idea to install MCNLive to harddisk, and do the remaster from there?

I can't realy imagine that VMware is an issue though, but maybe the remastering on the fly thing over and over and over does some weird things?

So, you are doing all remasters on the fly? And add. not from a real running CD but running from an iso in VM, and then remaster-on-the-fly?
And it is already the 5th or 6th level of remastering?
That means that you are never erally re-booting. Result: your inittab is wrong.
(On a livecd made with mklivecd there are two inittab files ...,and they are getting re-written dynamically)

Wow. It's a wonder that it is still working. It is about time that you get access to the MCNL dev forum where you can read the threads making the remaster feature work in MCNLive. Maybe you would understand better how sensible it is.

Some basic explanations.

A Live CD works different than a real installation. It has different/changed config files. One of it is the inittab. Even worse, but I can't explain it here.

When you are remastering-on-the fly you keep these changed config files, in some way. You never get a real clean MDV system. That usually is not a problem for a personal remaster, you won't even notice it. But in your case you have very special needs and you changed the basic system startup.

When you install MCNLive (the live cd) on a real partition, you also don't get a 100% clean MDV system. When you install it to a VM, you get an even less clean MDV system.

The only 100% sane and clean method to make a live cd for the public is to perform a real clean installation (on one / partition) from a standard MDV install cd/dvd and start from scatch. And do the build process from outside this system = when you don't run it. That is: in a chrooted environment.
It means: you have at least two MDV systems, the main system, booted. A second system (= your target system) which is not running.

It is a bit time consuming. Yes.

Yep, and it's the 11th level of remastering (thus the version number .11 )

That explains a lot!



I have sent a few PB's to Dansmug the last week, but I think he's busy

Hmmm.... I must say I have thought about doing something like this, but I liked the idea of MCNLive being the base system
The time consuming part is not the biggest issue, since like to learn from it. This is one of the main reasons I started the FreevoLive remaster

Ok, you are having several issues.

1./etc/inittab: Delete the ' autologin user blah ' stuff
There are at least 8 config files in MDV that are dealing with autologin etc. Autologin in MDV is done with the login manager (GDM or KDM). If you don't have one, you *do* need the autologin rpm. Otherwise the MDV init scripts are confuised. Install autologin and set it to: yes.
2. Do try to set inittab to 3, manually. MCC will refuse it if you don't have a login manager
3. On the running livecd, look at:
/initrd/etc/inittab
Make the changes here too.

You need to check this everytime you are doing a remaster-on-the fly!!!

4. I would not start freevo with .bash_profile
I am not sure if MDV will honor this.

5. startx is a special command, look at /usr/bin/startx
It talks to other startup scripts. Also the /usr/bin/startkde is worth to look at.

In general: because of the nature of a Live CD --- the startup scripts and commands are essential.
A Live cd has a very special/different startup process.

Oh, and please: don't try this if you are unfamiliar with mklivecd.
mklivecd is broken on a default MDV 2007 installation. You need to change a lot of things manually.
This would need days and weeks to debug and explain things to you. ATM I am running out of time.

A way would be to install MCNLive on one / partition. And start from this point. At least you get a real system with the working scripts and the prepared/already changed config files.

I am preparing mklivecd and some other stuff for 2007.1/cooker - and most likely more (new) things will be broken.

1. I'll take a look at this
2. I'm already doing this
3. I'll take a look at this too
4. Where do you think is a good point to start it? I thought .bash_profile would be a good place, since it's autostarted after login.
5. Another thing to take a look at!

I'll also try to stop remastering this livecd over and over and over again, and just create a system to master the iso from.

* Install MCNLive or FreevoLive to one / partition. Fix the bootloader
* Boot it. Make your changes. Boot it up again. Test it.
* Boot your main system. On your main system you need: a similiar MDV 2007 system. Installed:
mklivecd (just pull in the (non-working) mklivecd rpm from contrib, with all dependencies !!!), and after this manually replace all the scripts with those from MCNLive:
/usr/sbin/mklivecd
/usr/sbin/hwdetect
/usr/share/mklivecd/*

* Mount the new installed partition with the target system
* su, mklivecd --help
* If you are running different kernel versions on the two systems, you need to specify the kernel on the target system.
Example, a build command from the main system, the target system is on /mnt/hda7, and it is mounted:



This will place the file 'FreevoLive-blah.iso' on your running system, in your /home/<user> dir.
Adjust the dirs for the bootmsg/bootkey files.

You don't need to specify the tmp directory. It will use your default /tmp on your main system.
You should NOT use a tmp dir on the target system. (This is only useful when you are making a remaster-on-the fly)

Maybe i'm gonna implement FreevoLive at a customer today

Cool!

But please bear in mind that it has some problems still unsolved. If one would like to use it to install a dedicated Freevo box, this should work quite well, but KDE still crashes when ran from Freevo

Besides that, album covers aren't shown on the latest version (v 0.10 doesn't have this probem, but has Freevo 1.6.3 installed, not 1.7.0).

A little update for those interrested:

X/KDE does not crash anymore!!
I always had the idea that it was a bug in the commands plugin that caused this, now someone on the freevo-users list who does know Python, had the same problem, and solved it! It's been solved with one single extra line in the commands plugin.
Ths means we're able to do much more with FreevoLive then before. For example, installing it on your harddrive needed some handwork, because X crashed before you had time to finish the install!

This is the post from "the man"

Of course there are some other minor problems, but this was the biggest issue of FreevoLive until now!
Note that this does not mean I will release a .12 this week, as I'm installing a new system for the development for FL (which until now, was no more that an on-the-fly remaster of MCNLive, but I probably get spanked by Kris when I make another on-the-fly remaster haha )

You were already so drunk that you had implemented this already in version 0.11?
Serious, using version 0.11 X crashed during an internet banking session, throwing me back at commandline (not ' freezing' the pc). I restarted X with startx and I am now working for several hours on this pc.

Some (funny) test remarks:
Without finding anything he is 'scanning apple for trailers'
Sound (movie and music) works out of the box when Freevo is started. Monitor resolution is less then GeeXboX 2.0 which also uses Freevo.
Your Album examples don't give a sound, but my 'MCNL hardrock' collection is probing my little speakerbox to and beyond the utmost.
Configuring ethernet card with manual IP and without DNS (doesn't work because of the latter, which I unintended forgot) gives in MCC at manage Connections a search domain called
telephony.multikabel.net.
He, commercials about your provider aren't allowed!
Bye the way do you still use telephone instead of cable?

That it didn't got killed the second time, is because you ran it from the command line, not from Freevo
The bug is in the command plugin from Freevo, not in X or KDE itself

Oh ohhh, well throw 'em

What exactly do you mean by this? I indeed have enabled the appletrailers plugin, which is available from the video menu.
If you are connected to the Internet, it should scan apple.com for trailers, and provide you a list of online trailers which you can view directly from Freevo

Great, only not from TV I believe?

I just enabled the standard 800x600 resolution, because it runs on the framebuffer. Geexbox, as far as I know, is also running on the framebuffer... I'll check it to see how they did that

Hmm, strange that the exaple's won't work... they're just plain mp3 files downloaded from mp3.com

Ok, that means mklivecd doesn't remove that when doing a remaster
I don't know about the domain name, I do know that multikabel used that same name back from when they didn't even provide telephony

[quote name='HighKing' date='Mar 22 2007, 08:43 AM' post='81336'] If you are connected to the Internet, it should scan apple.com for trailers, and provide you a list of online trailers which you can view directly from Freevo [/quote]
If you are not connected to the internet, so just after booting and starting Freevo from LiveCD (in my case with static IP) it is searching my 'Apple' (indeed with a capital A). I thought I had a i586 pc

[quote name='HighKing' date='Mar 22 2007, 08:43 AM' post='81336'] Great, only not from TV I believe?[/quote] Wrong, also from TV-card, through audiocable to SoundblaserLive!

[quote name='HighKing' date='Mar 22 2007, 08:43 AM' post='81336'] I just enabled the standard 800x600 resolution, because it runs on the framebuffer. Geexbox, as far as I know, is also running on the framebuffer... I'll check it to see how they did that [/quote'] He, it is under the GPL, so using it is no offence

[quote name='HighKing' date='Mar 22 2007, 08:43 AM' post='81336']Hmm, strange that the exaple's won't work... they're just plain mp3 files downloaded from mp3.com [/quote] Maybe you better put exa-m-ples instead. My files were also mp3's and quite 'hard'

NL ik bergijp niet waarom mijn quotes niet goed werken.

Do you mean it starts to seach Apple during boot, of after selecting "Apple trailers" from the video menu?
The last is what "should" happen

Ok, cool. I thought it didn't work for you

The last, but is is funny that it is says 'scanning Apple for trailers' like ' scanning pc for files'

Meegeleverde MP3-tjes doen het wel.
MP3s which were shipped with FreevoLive do actually work.
Freevo heeft een beetje eigenzinnige gebruikersinterface (past wel ).
Freevos human interface is a bit weird (like me)
Muziekje kiezen toont lengte van het stuk en toont een tellertje 0.00. Pas als je op <Return> drukt start ie 'm op.
Choosing music shows the track and a counter at 0.00. Hit gain <Return> and it starts playing.
Op <Enter> drukken bij het numerieke gedeelte werkt niet.
Hitting the <Enter> at the numeric keys doesn't do that trick
Moet 'm toch eens met een game controller gaan uitproberen.
I have to try Freevo with a game controller.

Oeps Outsch it should be in English

Ok, I have set up a system with two MDV2007 installs on it, one with the mklivecd scripts from VirtualCity (I had to copy /usr/lib/syslinux/isolinux-graphic.bin from VirtualCity as well, that was not included in the syslinux rpm?)
So I did not install MCNLive or FreevoLive as the second system, just used a plain mdv2007 install, and it seems to work very well!!

Now I have to configure everything nicely
I'm thinking about leaving KDE out, and go for a smaller DE.

Yep, isolinux-graphic.bin is from an old MDV system. it is indeed necessary for our mklivecd.

I guess you will now see the next issues when you try to start the new created live cd.
Some config files need to be changed on the target system, /etc/rd.d/rc.sysinit and /etc/rc.d/halt

Copy those from mcnlive over to your installed system, is the easy solution. To learn more, run: diff on the files.

Cool, done that!
I see that rc.sysinit is not much different, only a lot of hashes were removed, halt on the other hand, seems to have much more changes.
For now I just copied them, when I have enough time, I will take a better look at it and maybe learn a few things from it

The 'halt' script is just the old MDV halt. The newer one will spit out nasty error messages when you shut down on a live system.
There is a more elegant solution, but I did not have the time to test them. And the old 'halt' just works.

Hmm, I f*cked it up yesterday, so I'll be making a new clean install again, and back it up before running mklivecd.
Why does mklivecd change a lot on the target system? Why is this not done in the tmp dir?
Well, as I said, I will be making a backup before running mklivecd, and restore that everytime after running mklivecd.

I made a new bootsplash btw:


The background is from the 'bluestar' theme, which I added the light effect with the Gimp, and simply pasted "FreevoLive" on top of that

Nice bootsplash

Copying the halt script from VirtualCity to my target system, and then running mklivecd from my main install, seems to overwrite some things... I did copy the halt from VirtualCity, but still the nasty error messages appear.
Even worse, the "Press enter" dialog doesn't appear, so the system shuts down with the cd still in it
(Ok, this has been the case with my on the fly remasters as well, but I hoped it would be ok now...)

With the original halt, I do get the press enter dialog, but also the nasty errors... (errors about not able to unmount certain things, are those the errors you meant?)

Also, on my 'development' system, a PIII 550, both MCNLive and FreevoLive won't boot normally. They need a keypress after the HAL is loaded, without asking for it (so if you don't know, you think the system froze).
I thougt maybe this would only be on this system, but the error seems to be copied over to the new live cd

So, the new livecd need this keypress on every system, not only my 'development' system.

If you have any idea, please tell me.
Else I will just make a new 'quick-n-dirty' remaster on the fly this week, so I at least can release a new version without the X crashing bug...

Do I need to install mklivecd on the target system as well (I didn't do that before), would that make any difference?

There are two 'halt' scripts.

The 'halt' in the mklivecd package --> /usr/share/mklivecd

The MDV normal 'halt' script --> /etc/rc.d/halt

1. You need 'all' the mklivecd scripts from MCNLive on your build system installed, these are in total 5 scripts, two in /usr/sbin, three in: /usr/share/mklivecd
You don't need them on the target system - unless you want the remaster-on-the fly function in the created iso.

2. You need to overwrite on the target system the MDV /etc/rc.d/halt in the default 2007 with the 'old' normal MDV 'halt' (for example from MDV 2006), or from MCNLive --> /etc/rc.d/halt
I already explained that.

3. mklivecd does not change anything on the target system - if it does you have the wrong scripts installed. It means you are running the broken scripts from contrib.
See ---> 1.
Or you use a very special build command that erases stuff on the target system ?

4. I have no idea why you need to press a key after HAL, sorry.

1. I coped the scripts you mentioned before to my build system, I'll look at that again (maybe something went wrong)

2. There is not halt in /etc/rc.d (Not in MDV2007, nor in MCNLive), there is a halt in /etc/rc.d/init.d though, so I thought you meant that one?

3. Again, maybe something went wrong in the first step then... because it does changes things. For example, after running the mklivecd script agains the target, and then boot the target system from harddisk (not the iso) I can see some things are different during boot (not sure what it is), and I suddenly can't delete files anymore without the -f switch.
(If I do rm file.ext, it asks to delete file.ext, but the file still exists after pressing 'y'. This problem is not there before running mklivecd. Note that this happens on MCNLive as well, on all systems I have tested it).

4. Damn... well my best hope is that step 1 went wrong then...
This is the only system I can use to this purpose, so if it doesn't work right, I need to do it in a vmware session

Sorry, yes, it is /etc/rc.d/init.d/halt

When you copy scripts make sure they have the same permissions as the original ones and make sure they are set executable if they are init scripts.

If this 'changing' stuff on the target system also happens with the original MCNLive, then you use the wrong build command. Post the 'exact' build command here, that is: mklivecd .....

I never saw this happen (only with the broken contrib mklivecd rpm, but in a very different way - for example it erases all users and creates a guest user).

You are using a P III, 500 Mhz as build and target system ?

Good luck, then. You really need a reliable hard disk and a lot of internal memory and swap partition to succeed.
My oldest system I used for building a live cd was a P IV 2 Ghz, but that is almost 2 years ago.

No, I meant that on MCNLive, I also need to rm -f to remove a file, just rm doesn't work.
And that the same thing happens to my target system after running mklivecd on it



Not everyone has the money to buy a new system
I have two faster systems, but one is my htpc, and the other is my wifes pc, so I can't play too much with those two...

There harddisk is a reliable one (40GB), and it has 768MB memory, which is a lot for a PIII system
It shouldn't realy matter though, might only be slower then on your P4

Edit:
Oh yeah, I forgot, even my laptop is faster... but building a livecd with a 1200Mhz laptop, with 256MB causes more pain than doing the same with a 550Mhz pIII

I just (re)uploaded FreevoLive 0.12, which is again a remaster of 0.11

I wanted this version to be out this week, because of the bad bugs introduced in Freevo 1.7.0, and the fix for the X crash The next version will certainly not be an on-the-fly remaster anymore.

The main fixes in this version are:
- No more X crash (bug in Freevo's command plugin)
- Fixed some unicode problems (also a bug in Freevo)
- Renamed the audio covers to 'cover.jpg', Freevo 1.7.0 is more strict in this then the earlier versions
- Enabled the webserver again, on port 8080
- Some cosmetic changes in X (deleted the 'choose language icon, renamed the MCNLive menu to FreevoLive, and put the draklive-installer icon on the desktop).

Actually I had uploaded the iso yesterday, but somehow the iso on the download repository was only 200MB, and thus broken. Found out about that when I was announcing the new version

I've upgraded!
My *new and improved* system is now an Athlon 2000+ with 512MB DDR400 ram, and the same 40GB hd.

Now, I have installed MDV spring 2007.1 2x, one time on the main system (keeping my old /home), and one time for the target system (one clean partition).
I copied the files over from MCNLive like you said in your earlier post, and copied the 'halt' from RC3 to my target system (renaming the old 'halt' to 'halt.old'.

Now, this still won't work right... making the cd with mklivecd works fine, the whole cd works, Freevo 1.7.1 runs great... all except for one thing: shutting down!
During shutdown of the live cd, I see errors that the system was unable to umount the loopfs (have not written down the exact errors, I will if you ask for it ), and the 'press ENTER' dialog is broken (I see the dialog, and the cd comes out, but pressing ENTER doesn't work, so the only option of shutting down is to turn off the computer by hand).
This, on the same system, with Delft RC3 works fine... with the same halt script...

Would you have any idea what I might have done wrong?

There are two halt script.

1. One in /etc/rc.d/init.d
(it is modified, replace it with the one from RC3, and make sure after you copied it that it is executable)
Compare it with the one in RC3

2. the halt.local from mklivecd --> on a HD installed system it should be in /usr/share/mklivecd
on a Live system it should be in /usr/share/mklivecd *and* in /initrd/sbin

3. make sure you don't use the wrong mklivecd script, make sure the permissions of the scripts are ok
make sure you use ***all*** mklivecd scripts from RC3, in total 5

---> most likey a user error :-P

PS: you need more changes on a fresh MDV 2007.1 HD installed system, a different rc.sysinit, an old isolinux binary .... I can't remember what more.

Since I kept having problems, I copied the mklivecd scripts from Toronto to my system... but now building takes about 45 minutes, on the same system... while it took less then 10 minutes with the old scripts...

Is it normal, that the new script is slower? Or is my system probably dying?

You copied scripts from Toronto to WHICH system? Based on what?

I tought it would be pretty clear to which system, but probably it isn't

I copied the scripts mentioned in this topic to my build system (not to the target system). This, because I keep getting problems (the same mentioned earlier in this topic), and kinda hoped the problem was solved with that

And what is your build system based on? Which MDV version? 2007.1 ?

If yes, then I don't know ...

Yes, see a few posts above where I already told that
But I think I broke my target system somehow.... restoring a backup of that partition now....

In general, the time to build an iso depends on:

* the CPU
* the size of the target system
* the available RAM
* the available SWAP
* the hard disk quality where the iso is stored

(and the version of squashfs kernel module and the squashfs-tools, but you can't choose them, you need to use those that are in your kernel and the matching tools version from contrib)

I understand, but my question was if it became slower with the version on Toronto... I guess it isn't according to your reaction
I'll try to find out what is going wrong now...

Ok. all problems are solved... well, I did a complete reinstall of both the main and the target system, with Mandriva 2007.1, installed mklivecd, and replaced all scripts by the ones from MCNLive Toronto.

Now, I finaly have a working master again!!!
On the FreevoLive website I posted this:
FreevoLive 0.13 BETA has:
- Freevo 1.7.2 (thanks to Korrel for the rpm again!)
- Kernel 2.6.17.13mdv
- No KDE, but XFCE 4.4 installed

Edit:
Forgot this, FreevoLive can be found at http://freevolive.tuxfamily.org/