Enable graphic root login on KDM would be nice (mzee asked for it, or was it Gerard?)

--> /var/lib/mandriva/kde-profiles/common/share/config/kdm/kdmrc
(or something like that)

change 'false' to 'true':

--->

Already did that meanwhile.
I'll edit my list above...

It was me Chris
For my rescue cd its very important to logon as root, so on my cd i already have done this
But thx anyway!

The second beta has just been released! I've edited my first post.

Congratulations.

Have been playing/working with it for a couple of hours. Everything seems OK. Mooi! Zeer mooi!!

But the Opera problem remains. Opera is unable to create a directory '.opera' in /home/live. if you create the directory yourself before using Opera then it is OK.

Have been adding some programs and even 'remastered on the fly'. Got an iso of over 700 MB. Will try now to put the iso on a usb-sick and try to boot from there.

One word : thank you for your efforts.

@mzee, I was just about to complain that you still hadn't answered my question on what version of Opera you were trying, when I noticed this post of yours:
Oooops, hadn't seen it yet... feeling a bit stupid now.
Will try the above rpm soon, I hope I can solve this for you.

Ok, I have been able to reproduce the error, but I'm not sure why it happens and if it is an MCNLive specific problem at all.
When I install the rpm you mention, and run Opera for the fist time, a dir .opera is created, but with wrong permissions:
Trying to rmdir this directory makes the system completely unusable for the live user.

In tty1 as root. No problem, but whenever I try an ls in /home/live the root session hangs as well.

Rebooted. Installed Opera again. Ran it, same directory with same permissions was created.
Chmod'ed the .opera directory to 700: Problem solved.

Veeeeery strange...

Edit:
First I thought maybe the sticky bit is the problem, but creating a test directory with the sticky bit set as well was no problem. Removing it neither.
Next, I simply created a test directory and chmod'ed it 400. Tried to rmdir that testdir: same problem!

Might be a unionfs/tmpfs problem... not something I can solve...
Question is: Why does Opera create a directory without write permissions for the owner?

Ok, it's a unionfs problem... maybe even a bug, but sadly nothing I can fix.

You can easily reproduce this on an mdv2010.0 system by mounting 2 directories with unionfs. I tried merging 2 dirs with unionfs. Then created a directory 'test' inside it. Chmod'ed it to 400 and tried to rmdir the directory. I had to reboot in order to regain control over my system. Note that this was NOT on MCNLive, but on my laptop with a MDV2010.0 x86_64 installation. Since MCNLive uses unionfs to merge the root with tmpfs to make it writeable there is not much we can do about this.

Wish to thank you for your kind reactions. Thank you very much for trying to tackle the problem. At least we know now where the problem lies and we have a way to go round.

May confirm that remastering on the fly is really easy. An putting the iso on an usbstick is also not a problem with 'dd' . (Do not forget to remove "grub" first if necessary!)

Have one more question, if you allow me. The boot option 'fstab=rw,noauto' doesn work. How to prevent the system to mount the available partitions?

Once more : dank!

I'll try to find some solution, but am not sure if I'm able to.

That bootoption doesn't work. I have a "special" script that configures the system at boot. The same script mounts all local partitions. I didn't provide an option to override this... will try to add it.

Danke!

Can we not make the folder .opera with the right permissions on the livecd on default, if someone than installs opera than it should work ?

That is one idea that came to my mind if we're not able to create a better solution indeed.

'Joe ar good busy folks'
Jullie zijn goed bezig mannen (en vrouw)
You all are donig wonderful things

I close me there to on.

Haha, maybe we should start a 'dinglish' version of this topic?
(Anyone read the paperback 'I always get my sin'?)

Does anyone have a good idea on how to call a new bootoption that prevents mounting local partitions? It can be anything, from donotmountlocalpartitions to ilikecherrypie or ronisacrazyman.
I just can't make up a good bootoption name...

Bootoutlandos, from Outlandos d'amour (the Police), it is spring, like Mandriva 2010 is.
Outlandos for sure not local, sounds like far away, like things we love to have booted in our systems.

I prefer a more obvious bootoption, like donttouchmypartitions, but that's a bit too long for people to remember.

What about 'nomount'?

Regards.

not mount internal

MCNLive-Beta-2...

Live Install... on a testing PC:
P4 2400Mhz with 1.5 Gig Ram
nVidia FX5700
HD 20 Gig

RPM's added:
gFTP, MC, qCAD
Keyboard chaged to AZERTY BE

No problems.

MauRice

Simple yet effective!
Seems ok to me.

Got a PM from Tux Brothers with a remaster question, but he mentioned that fonts look way better when we use Mandrivas' own libfreetype6 package instead of the one from PLF.

Going to give that a try.

Ok, the bootoption "nomount" works. Was not hard to implement by the way.

Fonts seem to look better with libfreetype6 from mdv.

About unionfs (the file system that combines the contents of the squashfs-file with a tmpfs mount): When I modprobe unionfs on my laptop, I see this in dmesg:
This is strange... because the unionfs website mentions you should use a 2.x version on kernel 2.6.31...

http://www.filesystems.org/project-unionfs.html


Edit:
Made a bugreport: https://qa.mandriva.com/show_bug.cgi?id=58276
I hope MDV takes this one serious...

beta 2 test.

1. mkhotremaster still looking for ntfs partitions, and not for fuseblk. I've edited the script, works.
-- the script looks weird while working, doesn't scroll in the terminal.
-- doesn't tell clearly when it's finished ;-) Could the script be a bit more verbose?

2. Opera: I've created an empty .opera dir (/home/live/.opera) first, and installed opera. That works

3. KDM: log out, root login isn't offered. Manually typing root, and password root, I get a red background and the startup sound, then the system hangs.
Probably a temp. problem, I worked in VirtualBox, installed a lot of stuff, un-installed, changed settings, and made a remaster, then tried the root login. Maybe I was running out of RAM, dunno. 700 MB for the virtual machine...

---> This thread is hard to find because it is in the NEWS forum, not in the MCNLIve International forum.
Can we have a thread that isn't hidden under NEWS?

Thank you very much.

Do we have to wait for Beta3 to get that option or is there a way we can change Beta2 and then remaster?

Have a nice week-end!

Or bring it in into the official release.

And this is what things look like whit libfreetype6 from plf, and kde's antialias settings back to "use system settings":


Ok, or should we re-enable kde's antialias settings?


In the meantime, the system was fully updated which means KDE is now at version 4.3.5.

Would say, leave it this way.
Looks just nice.

Somehow missed this reply of yours Kris. I'll answer inline.

I somehow forgot to edit that in the original file... did that now.

Which is the way it looks like since the last alpha. I you have an idea on how to make this better looking I'll be happy to hear it. Using konsole like in the old remaster script is not an options as konsole backgrounds which makes the script go on with the next part while the mkhotmedia script is still running.

Maybe "zenity --progress --pulsate" followed by a status message would be a better idea?


It says it is done in the console window, but as that doesn't auto scroll it is indeed a bit unclear.

I know. I did the same already. Was hoping for a better solution but this at least works for Opera.

I though making root logins possible would be enough.
I'll try to add root to the list.

Got the same after doing loads of things in a vbox sessing with only 512Mb ram. Guess it is indeed a memory problem as this does not happen when you directly log off and log back in as root.

I know. Someone moved my topic to news without asking.
I'll create a new topic for the upcoming "rc1" and edit the text of my first post to point people to that topic.

It will be in the next release, but if you'd like to add it to a remaster it is not that hard to do.
The script is in /etc/init.d and is called hmconfig.

Before the mounting part, you just add a line "if ! grep -iq nomount /proc/cmdline; then" and at the end of the mounting section you add a "fi". That's all. then you can use the option "nomount" to make sure the mounting part of the script simply doesn't run.

@HighKing:

* the mkhotremaster zenity script

I can't remember how we did it on the old MCNLive, but the zenity GUI should be usable for an average user. The last message shouldn't be a konsole message, but an info Zenity screen, with a text: Your blahblah.iso is ready/written. Where you can click 'OK'.
And why do we need the konsole window at all? Can't this be done in the background while we see a zenity window: 'Be patient, remastering in progress'. When done, the next, final zenity screen appears.

I'm sorry I forgot how to work with zenity.
The command line script doesn't have this weird behaviour, why does it only occur when running zenity?

Sorry to be such a pain with usability issues, but I'm trying to slip into the mind of an average user.

* the fonts problem: I give up. What is the new problem. I don't understand. Can't you SEE the difference when you create a test iso?

The old remaster script used konsole to show the progress as zenity's progressbar wasn't very useable. I think however that with the --pulsate switch we might be better off using that and create some check at the end of the remaster script to see if an iso file was written and notify the user of the exit status.

I might not care as much as you do, offcourse I see a difference but I don't see a problem in the last screenshot... according to your reaction I guess you do?
If I compare the last screenshot with the first one, I think the latest looks way better... you don't?

I can't see it on the screenshot. But I will on the next beta, I guess.
YOU should see it when you compare your 'normal' standard MDV install and compare it with your next MCNLive version, that's what I meant.

As said, I see a difference, but I don't see a problem.
I see that the fonts look better then before now, but I didn't think they looked disguising before... I only think they look better now.

About the remaster script: I just tried it with "zenity --progress --pulsate" but that kinda sucks... there is a cancel button which doesn't work, not very userfriendly.
Can someone please try to help out by making the progress look better? I'm out of ideas...

I have no clue what the state of the fonts are 'now' in your version.

* libfreetype MANDRIVA (not PLF)
* if above, then: KDE doesn't need ANY changes, it should use the 'system settings'. IF the system settings are ok, but I don't know IF they are ok now.
* ---> all changes you made _manually_ in 3 or 4 kde config files _in theory_ should be reverted.

Sorry, but from the first version of the MCNLive I saw the fonts were screwed, in a way I never saw on a MDV system. I never had to adjust fonts on MDV.

Just create a test iso, and look how it goes. I really can't tell you, because NOW you went back to the MDV libfreetype, but since you never boot your build system it's possible that the system settings are still not back to normal.
Ok, and now let's leave the font problem. I can only repeat again and again what I already posted for weeks in the dev forum, .
For me personally, it is very important, but that's just me.

If you have read my last few posts, you know that that's exactly what I did on the version of the last screenshot.


Yeah, but the system was not booted after the plf rpm was installed, so that can't hardly be a problem.

Oki, Michel. All will be fine

Last night I did some crazy stuff, mimicking again an 'average' user. That's fun.

* I installed MCNLive (hard disk install, virtual box)
* Made from a KDE system an XFCE version.
* Had a look in the menu, aha, found the menu entry: make a remaster.
* Ran the zenity mkhotremaster, as root. On the installed system.
* error message: something with 'halt'
* Bumped out, 'no partitions found' -- what? I'm on an ext4 system with enough space left.

* Can't shut down the system, because mkhotremaster renamed 'halt'.
* And prob. the script activated hmconfig.

My installed system system was a little bit of a mess afterwards.

Do we need a sanity check for mkhotremaster (are we on a live system?) before we run it?
Or just delete the menu entry after the installation?
Or can we make it work on an installed systems?

A small issue, we need a small background picture file with the name 'default.jpg' in /usr/share/mdk/backgrounds. Otherwise if a user installs gdm as login manager (I did for an XFCE system) the graphical login has a nasty problem.

I have another question: does anyone know why I can't un-install the kde NL localisation without erasing the whole KDE desktop?

An avarage user that replaces KDE with XFCE?
I believe running the remaster script from the menu will be a problem as that uses kdesu to start the script.


I know, this is fixed in my new remaster script... the problem is that the original halt script was put back in place when you started the script, but since the script didn't finish, it didn't reach the point where the live halt is put back in place.

It should work fine on an installed system, I believe both MauRice and willie have done that already.
Could you please try to debug your problem a bit more?

Ok. will add it.

I have no idea...

Please try my latest remaster script before going on:
http://www.mcnlive.info/downloads/mkhotremaster

I'm not too happy about the zenity --progress thing though.

I'm not sure if have enough time for testing until Thursday

I had a look at the new script.

I'd like to suggest to move these commands:



after the partition check, this way if the script errors out we don't get the mess.

Or even better, move all relevant commands to mkhotmedia so that mkhotremaster/zenity serves only as a wrapper. Perhaps we can do that for MDV 2010.1 ?

And I'm not sure if we actually have halt.orig after installation in /etc/init.d
I believe I didn't, that's what caused not being able to shut down.

Can someone with an installation have a look?
An can Maurice and willie confirm here that they made a remaster from a HD install?

Oh, and I'd like to ask a forum mod to move this thread to MCNLive International. We're beta testing here, in a NEWS forum, .
Or should I open a new thread?

Please be a little more patient.

Ok I'm trying from the start.

1. I have a remastered (in live mode remastered) mcnlive cd.
2. I start this remaster, and while booting I already get an error message, I believe it's during the live init: ' can't rename ...blah halt ... no such file or directory'
3. On the booted live system I have:
- /etc/init.d/halt
and
- /etc/init.d/halt.mcnlive
(looks like this is the original MDV halt)

Next step: I'll install this already remastered system to HD.

BRB - this will wipe out my sweet XFCE desktop

:: A few minutes later::

System is installed, and I've got, on the hard disk:

/etc/init.d/halt <---- that is is the LIVE halt, on the HD installed system, ohhh?
and again
/etc/init.d/halt.mcnlive

BRB :: I'm going to boot from HD now.

Ok, back ::

On my installed system I also have:

/mnt/sda1 (huh???, on sda1 is my installed system)
and I've got:
/mnt/install/ ..... with a lot of subdirectories, /install/var/lib/ and so on

Tomorrow I'll test the remaster script from the HD install.

Moved.

Nice, but now you have a crappy looking frontpage.

That's because it's moved, hehe. A good reason to put out a new release, isn't it?

If I could get a little help I could finish the next release much sooner, so...

Ok we need to rethink something... after installing the live system to disk the live halt stays in place. This is wrong, but since the installer isn't ours we can't do much about that. How does One handle this? Does it use a custom halt script at all?

One idea that came to my mind is keeping the hmconfig script enabled after booting, and create a check in that script that checks if the system is live or installed and removes the live halt whenever running from an installed system. Then the hmconfig script can disable itself after the first boot from an installed system. I would prefer the installer to do this for us though... but I'm affraid that's not possible.

HighKing, what do you mean by "live halt"?