FreevoLive .11 opties

[HighKing]

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!

[HighKing]

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.

[kris]

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 ?

[HighKing]

I've tested 0.11.

Small isssues, easy to fix:

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

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

Didn't notice that...

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

W00P!

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

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

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 ?

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?

[kris]

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.

[HighKing]

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

[kris]

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)

[HighKing]

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.

[kris]

This runlevel stuff is kind of weird.

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

[HighKing]

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?

[kris]

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.

[HighKing]

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?

[kris]

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.

[HighKing]

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?

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

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)

That explains a lot!

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.

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

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.

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

[kris]

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.

[kris]

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.

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.

[HighKing]

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.

[kris]

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:

mklivecd --verbose --root /mnt/hda7 --kernel 2.6.17-11mdv --bootmsg /home/chris/myboot.msg --bootkey F1=/home/chris/help2.msg --bootkey F2=/home/chris/myboot.msg FreevoLive-blah.iso

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)

[doelman]

Maybe i'm gonna implement FreevoLive at a customer today

[HighKing]

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).